Authcontrol v4 Sentry SSO and Adaptive Authentication
Contents
What is Adaptive Authentication?
Swivel Secure's AuthControl Sentry adds to the existing Authentication platform a new means by which you can manage the way users access a range of on-premises and cloud applications. Specifically if and how they need to authenticate in order to gain access to those services. We refer to this aspect of the product as Adaptive Authentication, as you can select your authentication requirements depending on the application you are protecting.
Sentry applies a number of rules to determine which authentication method a user needs to complete before accessing a specific service. It does this by comparing the Trust Score a user achieves according to the rules and the Require Trust Score required for the service that the user is attempting to access and then offering the user a choice of authentication options that will increase their trust score to the appropriate level.
Where we need to refer to the authentication platform web administration console (on port 8080), we will refer to this as the Core.
- Application
Generic Name for remote access/cloud/web application. Could be for example Saleforce.com, OWA or SSL VPN
- Trust Score
An overall assessment of how much confidence we are that this is a valid access request
- Required Trust Score
The required trust score a user is required to demonstrate to be allowed access to an application
- Rule
An element of logic that is used to help create an overall assessment (Trust Score) of the level of confidence associated with a specific authentication request
- Authentication Method
One of a number of ways that a user can be asked to authenticate.
Getting Started
Login to Sentry for the First Time
Login to Sentry using URL https://<INTERNAL_DNS_OF_SWIVEL_APPLIANCE>:8443/sentry and accept the EULA. If you can't gain access to the Sentry Admin Console, try another restart of Tomcat and wait 10-20 seconds or so before trying again.
Settings
You can generally access the Adaptive Authentication Admin console using the same username and PIN from a Admin Account on the Core server that it is working with. However you may need to change some settings first if you are running a non-standard installation.
Instructions below refer to a location <swivelhome>. This is the base directory containing the settings files for all Swivel applications. On an appliance, it is /home/swivel/.swivel.
The following settings are under <swivelhome>/sentry in a file called settings.properties.
The first section dictates how Sentry should communicate with the Core Server. It is recommended you change the default secret before putting into production.
pinsafessl=false pinsafeserver=localhost pinsafecontext=sentry pinsafesecret=secret pinsafeport=8181
The next section dictates how Adaptive Authentication should retrieve images from the core
imagessl=false imageserver=localhost imagecontext=proxy imageport=8443 selfsigned=true
This entry determines which Core server group a user must be a member of in order to access the Adaptive Authentication Admin console. If you want the same users to administer both Adaptive Authentication and the Core, you can generally leave this setting at its default as shown below.
administrationGroup=SwivelAdmin
The administration group attribute can be specified through the CMI menu, Appliance Menu > Sentry Menu > Set Administration Group
Accessing the Web Administration Console
If the settings are correct then you can access the admin console login by going in a browser to http(s)://<swivelserver>:8443/sentry and then following the link to the admin login. Here, <swivelserver> is the IP address or host name by which the Swivel appliance is accessed.
You can then login to AuthControl Sentry Adaptive Authentication using the same credentials as for the core Sentry administration.
Troubleshooting Login
- If no TURing image appears, check that the settings.properties are correct for your installation.
- If you see a session start in the Core logs but no authentication request then check the settings for pinsafeserver etc in settings.properties.
- If there is an authentication request but the Core logs indicate that the agent is not authorised, check that there is an Agent defined on the core administration for localhost (127.0.0.1), and that the secret for that Agent matches the one in settings.properties.
- If the Core indicates that the authentication was successful but you still cannot access Adaptive Authentication, check on the Core that the user is in the group defined in settings.properties, e.g. SwivelAdmins.
- If you cannot reach the Adaptive Authentication Admin Console it may be because access to the admin console is not possible from your IP Address. Check the settings in <swivelhome>/sentry/security.properties. This file shows the IP Addresses from which the admin console is accessible. The default is admin.iprange=0.0.0.0/0 which allows access from anywhere. A setting of 192.168.0.0/16, for example, would restrict access to the 192.168.x.x address range.
Setup Sentry Keys
Before you are able to create a Single Sign On configuration, you will need to setup the application URL and some Keys.
To specify the application URL you need to use the appliance CMI Menu. Select the Appliance menu, then select Sentry Menu and then select the option Set Application Root URL.
Keys are used to secure the communication between Sentry and Cloud Services. Please see a separate article: How To Create Keys On Cmi.
You will need to use the certificate you generate when creating SAML integrations. This can be retrieved from the View Keys menu option of Swivel Sentry
Viewing Certificate and Metadata
The certificates you have created will be required by cloud services in order to secure the communications between the cloud service provider and the Sentry installation. The certificate information is contained within the Sentry IdP Metadata and can be access by the cloud service provider via the View IdP Metadata link.
If the cloud service provider is not able to consume this metadata, the actual public key and certificate are also available for download from the Sentry Admin Console.
Defining Applications
Applications that support federation standards such as SAML and ADFS will use those standards to integrate with Sentry. Legacy applications and services will need to integrate in a different way and they will use Swivel Secure’s Proprietary Claims approach which works in a similarly way to SAML but works with the constraints of non-cloud systems such as VPNs.
The flow is as follows:
- The user goes to the Sentry Universal Login Page and selects the VPN application.
- The user is asked to present credentials as per the policies and the Sentry uses these credentials to request a Claim for that endpoint.
- The user is redirected to the VPN login page with the claim as the password parameter.
- The user logs into VPN using their username and claim.
- The core then validates the claim, checking that the claim was issued for this endpoint. So in this case the Application name on the Sentry must match the NAS name on the core.
To create a new application, go to the Applications section and click on Add Application:
A list of default applications will be displayed. If the application that you need to integrate with does not appear on the list click SAML-Other or RADIUS VPN-Other depending of the integration type required.
Example SAML Application:
By default, Sentry returns a single assertion, using the federated ID as defined in the application. Note that this value must correspond to a Sentry attribute defined in the Sentry Core. You can request additional SAML assertions by clicking "Add Attribute"
The name and format are dependent on the target application. All attributes must be defined as custom attributes in Sentry.
There are some application images added by default. If you need to add a new application image or update the existing ones, please go to the section Application Images.
Defining Authentication Methods
Sentry supports a range of user authentication types. These can be assigned different numbers of points. Generally, the stronger the authentication the more points are allocated to the authentication type.
For example, if you were using Sentry to protect two services, one more security-critical than the other, you could enforce two-factor authentication for the more secure service by
- Making the required trust points for the more secure equal to 200 and 100 for the less secure.
- Allocating 200 points to two-factor authentication types (e.g. token) and 100 points for Image-based authentication (e.g. PINpad).
Then when the user attempts to access the more secure service they will be prompted to use a two-factor authentication method and only be allowed access if they complete authentication in that way.
You can assign any scores you like to any authentication types, being mindful of the points required to access services and the points that a user can gain from the rules.
All authentication types are enforced by the Swivel Core Server. Current Supported Types Are
Password Check of Users Repository (eg AD) Password
TURing Image-based authentication via TURing Image
PINpad Image-based authentication via PINpad Image
SMS SMS-based authentication
Soft Token AuthControl Mobile Client Authentication
OneTouch AuthControl Sentry Push Authentication
OATH Token OATH Hardware Token
If a type of authentication is allocated zero points, it means it is not supported by this installation of Sentry
When a user tries to access an application, they will be offered the lowest point authentication method, although they can select an alternative method if they choose. By default, the user will be able to select all authentication methods.
Alternatively, an administrator can select the option only to show authentication methods for which the user has the rights to use. To do so you have to go to General Configuration and tick Show Allowed Authentication Methods By Rights check-box. This way users will only see authentication methods that they can actually use.
When a user accesses the service and is shown the authentication method, the authentication method will also show the service name / logo to indicate which service the user is trying to access.
Defining Sentry Rules
By allocating points to Services and Authentication Types, you can use Sentry to implement a set of static rules that dictate how a user needs to authenticate to certain services. Sentry rules allow you to add a dynamic element to user access, meaning that you can refine the access rules to reflect the specific risk elements of a user’s access.
To define a rule, you set the parameter for that rule and then the score when that rule is valid. For example, for IP address you specify the IP address range and a score. The user will be allocated that score if their IP address is part of the specified range. Scores can be positive or negative.
You can specify multiple rules of each type
You can currently specify rules based on the following user and environmental attributes.
IP Address (White List or Black List)
These rules allow you to add trust points if the user is coming from a whitelist IP address or deduct points if the IP address is on a blacklist.
Parameters:
IP Address Range, e.g. 192.168.0.0/24
Examples
Time Range
Allows you to add points or deduct points based on the time of day that the user is attempting access.
Parameters:
Start of Time Range: Start of time range of interest
End of Time Range: End of time range of interest
Example:
Certificate
Allows you to add points if the user has a valid client-side X509 Certificate installed
Parameters:
None
Example:
For further details on configuration, check Client Authentication using Certificates
Group Membership
Allows you to add or deduct points based on whether a user is a member of a particular group.
Parameters:
Name of Group. The name of the Sentry Users group that is of significance.
Example:
Known IP
Allows you to add points if a user is attempting to access a service from an IP address that they have successfully accessed before.
Parameters:
Maximum Number of IP Address: Sentry will record up to a maximum number of IP addresses that a user has successfully authenticated from to cover for example home and office IP Addresses
Number of Days since Last Access: The number of days after the last successful authentication that an IP address will be treated as being significant.
Example:
GeoIP
Allows you to add or deduct trust points based on from which country a user is attempting access, according to their Geo IP location.
Parameters:
Country Code: List of ISO-3166 standard country codes related to this rule. List is comma separated, eg GB,FR
Example:
Geo Velocity
Allows you to add or more likely deduct points based on the user's apparent average speed since their last login. This uses their Geo-IP location at their current and previous location, and the elapse time. This rule is primarily designed to detect logins from someone other than the authorised user, at a geographically remote location.
Parameters:
Speed Limit (MPH): the average speed which must be exceeded for this rule to apply. Note that this is in miles per hour.
Example:
Compound Rules
Compound rules allow you to combine already created rules and accessing applications to add or deduct trust points for the user.
Rules can be combined to support both simple and complex set of access rules. For example you may decide that Username and Password from a Known IP Address in a safe country is as safe as two factor.
Parameters:
Rule/Application 1: A List of Rules and Applications
Operator: Operators AND,OR,XOR,AND NOT. Will allow to select if you want both rules/applications to be true to give or deduct trust points or one of to be true, or one has to be false etc.
Rule/Application 2: A List of Rules and Applications
Example:
This also allows you to specify rules that only apply to specific applications e.g.
Single-Sign-On
Single Sign-On allows a user to carry points that they have attained by authenticating to one application when authenticating to another application (within the same browser session).
This means that if a user has authenticated to one service they will be automatically logged-on to another service that has the same or lower required points value.
To enable single-sign-on select the SSO Enabled setting under General Configuration.
For RADIUS VPN applications the credentials will be required to access if the application does not have any session active.
Setup Authentication for Start Page (Optional)
If needed, from 4.0.5 onwards, you can configure the points required to authenticate before showing the start page.
In General Configuration, enter the Points Required for Start Page.
If you specify more than 0 points, you will get the RBA Login to enter the Start Page.
Additionaly, it's possible to configure what applications are shown in the Start page per user group, by going to the application page and selecting "Restrict by Group".
General Operation and Diagnosis
Users Active Sessions
The Users Active Sessions Screen will display any users that are currently logged in via Sentry and it will indicate how many points they attained as part of that authentication.
User History
The User History Screen will display a user’s recent login history, including IP address, access date and points. If there is any GEO IP rule defined, the location of the user’s authentication will be displayed as well.
The user history information is used by the known IP rule, so if a Known IP has been defined, the number of last logins stored will depend on the information set on the rule. This screen also allows an administrator to remove the records associated with a user.
Log Viewer
The Sentry server logs authentication and other events, which can be viewed on the Log Viewer page.
You can choose what level of logs to view from the drop-down list.
On General Configuration, you can select if you want to delete the logs and if so, how long to keep the logs.
By default Delete Logs Older Than (days) is set to 30. If that value is set to 0 the logs will not be deleted. If it is set to 1 it means that the logs will be deleted that are older than 1 day.
The scheduled task to delete logs by default will run every day at 23:00. This can be changed if the attribute deleteLogsJobCronExpression is added into settings.properties, e.g. deleteLogsJobCronExpression=0/5 * * * * ?.
