Adaptive Authentication Tab Configuration
Introduction
SecureAuth IdP's Adaptive Authentication starts immediately after a username is authorized against the enterprise directory, with an instant response to an authentication request. The Adaptive Engine's analysis determines whether a user should be passed, required to provide additional authentication, or denied access to the protected resource.
Adaptive Authentication thwarts breaches based on configured pre-authentication policies that require the bad actor to trigger one or more specified rules. For example, if the user attempts to authenticate from a blocked country (geo-location blocking), or attempts to VPN from a command-and-control server associated with a "bad" IP address (Threat Service), then authentication requirements are stepped-up, halting the bad actor's efforts.
In SecureAuth IdP version 9.2, a new offering is available from SecureAuth's Prevent Threat Service package. Advanced adaptive capability powered by machine learning tracks and analyzes the login behavior patterns of authorized users for a period of time to identify their normal patterns, and then assigns each user a personal risk score. Bad actors' attempts to impersonate authorized users in order to gain access to the targeted site fail, since a login behavior pattern and risk score are unique to each user. See Machine learning User Risk Score calculations in Adaptive Authentication (version 9.2) and SecureAuth IdP 9.2.0-19 hotfix for machine learning deployment for more information.
Adaptive Authentication Features
Adaptive Authentication includes these features for enablement:
IP Address / Country Restriction: Restrict access by IP address(es) or country code(s)
IP Reputation and Threat Detection (for version 9.1) or SecureAuth Threat Service (for version 9.2): Restrict access based on risk factors and threat intelligence by IP Address evaluation
User Risk: Restrict access based on user reputation and / or user behavior factors
Any of the above features requires a special SecureAuth license – contact SecureAuth Support to upgrade
User / Group Restriction: Restrict access by end-user(s) or user group(s)
Geo-velocity Restriction: Restrict access based on the current time and location of end-user compared to time and location of end-user's last access
Adaptive Engine Actions
Prerequisites
1. Ensure SecureAuth IdP v9.1+ is running
2. Create a New Realm or access an existing realm in which Adaptive Authentication will be utilized in the SecureAuth IdP Web Admin
3. Configure the following tabs in the Web Admin in addition to configuring Adaptive Authentication:
Overview: the description of the realm and SMTP connections must be defined
Data: an enterprise directory must be integrated with SecureAuth IdP
Workflow: the way in which users will access the target must be defined
Multi-Factor Methods: the Multi-Factor Authentication methods that will be used to access the target (if any) must be defined
Post Authentication: the target resource or post authentication action must be defined
Logs: the logs that will be enabled or disabled for this realm must be defined
4. (OPTIONAL) Have a special SecureAuth IdP license to use IP Reputation / Threat Data analysis function (version 9.1) or SecureAuth Threat Service (version 9.2)
Contact SecureAuth Support to upgrade the SecureAuth IdP license
5. (OPTIONAL) Have an on-premises SailPoint IdentityIQ and / or Exabeam UEBA solution to use the User Risk analysis function
See Connecting SailPoint IdentityIQ to SecureAuth IdP 9.2 and / or Connecting Exabeam UEBA to SecureAuth IdP 9.2 for information about using SailPoint / Exabeam with SecureAuth IdP for the user risk score function
NOTE: In version 9.2,user risk analysis involves the use of risk scores to handle authentication requests. In version 9.1, policies are used to handle authentication requests.
Note
See Authentication API guide and Adaptive Authentication API Guide for information about configuring APIs
SecureAuth IdP Configuration Steps
Data
Note
This step is for LDAP data stores only, and if enabling the User / Group Restriction and / or Geo-velocity analysis features
 |
1. In the Profile Properties section, map the Groups property to the directory field (e.g. memberOf) that contains the user's group information in Active Directory
This step is required if enabling User / Group Restriction
2. Map the Access Histories Property to a directory field that fulfills the following requirements:
The Access Histories Property can be stored as Plain Binary or in JSON format, and has distinct requirements for the LDAP directory attribute mapped to the Property based on the Data Format selection
For Plain Binary, these requirements must be met for the directory field that contains the Access Histories information:
Length: 1024 minimum per Access History record (NOTE: The Access History setting is configured in the web.config file:<add key="AccessHistoryMaxCount" value="5" />)
Data Type: Octet string (bytes)
Multi-valued
For JSON, these requirements must be met for the directory field that contains the Access Histories information:
Length: No limit / undefined
Data Type: DirectoryString
Multi-valued
In typical AD deployments, the Data Format is Plain Binary and the photo directory field is utilized
3. Check Writable to allow SecureAuth IdP to write information to the Access Histories Property
Steps 2 - 3 are required if enabling Geo-velocity
Notice
The Properties must be mapped in each realm in which the User / Group Restriction and / or Geo-velocity analysis features are used
Warning
Click Save once the configuration has been completed and before leaving the Data page to avoid losing changes
Adaptive Authentication
 |
On the Adaptive Authentication page, in the Adaptive Authentication section, adaptive authentication factors enabled on this page appear in the table
Drag and drop selections to reorder the processing sequence
User Risk
 |
Notice
These User Risk steps provide information configuring a user risk solution supported by SecureAuth IdP. A SecureAuth Prevent Threat license is required for using the User Risk feature in version 9.2.
See Connecting Exabeam UEBA to SecureAuth IdP 9.2 or Connecting SailPoint IdentityIQ to SecureAuth IdP 9.2 if using the SailPoint or Exabeam user risk solutions.
4. In the User Risk section, toggle the switch to Enabled to enable this analysis feature
5. To configure the user risk score provider, click edit
User Risk Score
 |
6. Use the sliders or input values to configure the Risk Ranges for:
a. Minimum - 0 by default
b. Medium - 50 by default
c. High - 60 by default
d. Maximum - 100 by default
7. Click Save to preserve settings and to close the window
8. Under User Risk Score Actions, specify the action SecureAuth IdP will take if the user risk score falls within the specified range by making a selection from the dropdown (see Definitions for more information on actions)
a. High Risk - SecureAuth IdP will execute this action if the user risk score falls within the upper range
b. Medium Risk - SecureAuth IdP will execute this action if the user risk score falls within the middle range
c. Low Risk - SecureAuth IdP will execute this action if the user risk score falls within the lower range
d. Score Unavailable - SecureAuth IdP will execute this action if the user risk score cannot be retrieved
This action can occur if the user is not found in the data source or does not have a score assigned in the data source
See the Knowledge Base article Unable to Communicate with the User Risk Adaptive Authentication Data Provider for more information if SecureAuth IdP is unable to communicate with the data source
9. (OPTIONAL) To add a new risk provider, click Add User Risk Score Provider – this step requires an on-premises risk score solution configured for use with SecureAuth IdP
Add New Risk Provider
 |
9a. Configure the Risk Ranges for Minimum, Medium, High, and Maximum risk scores
9b. Under Connection Settings, enter the Risk Score Provider Name
9c. Enter the Base URL of the user risk solution instance in the format https://services.company.com:59
9d. Enter /api/user/{username}/info in the Get Profile Relative URL field
9e. Select the Authentication Method from the dropdown – i.e. Basic, OAuth 2.0, Cookie
9f. Enter a Username from the provider service account which can retrieve user profile information
9g. Provide the Password associated with the Username
9h. From the Risk Score User Identifier dropdown, select the field to store the user risk score – which is either the Authenticated User ID (default selection), or the directory Profile Field mapped to the Property on the Data page
Note
NOTE: If using an available Property to store the user risk score, REST must be selected as the Source, and {userInfo}{riskScore} entered in the corresponding Field
See the sample image showing the Phone 4 Property selected
 |
Property selections available from the Risk Score User Identifier dropdown include:
Phone 1
Phone 2
Phone 3
Phone 4
Email 1
Email 2
Email 3
Email 4
Aux ID 1
Aux ID 2
Aux ID 3
Aux ID 4
Aux ID 5
Aux ID 6
Aux ID 7
Aux ID 8
Aux ID 9
Aux ID 10
9i. Enter {userInfo}{riskScore} in the Risk Score JSON Path used by the Risk Score User Identifier
9j. Click Save to preserve settings and to close the window
 |
Notice
These User Risk steps provide information on enabling and configuring User Risk which requires a SecureAuth Prevent Threat license for use with SecureAuth IdP – and also information on configuring another user risk solution supported by SecureAuth IdP.
See Connecting Exabeam UEBA to SecureAuth IdP 9.2 or Connecting SailPoint IdentityIQ to SecureAuth IdP 9.2 if using the SailPoint or Exabeam user risk solutions.
4. In the User Risk section, toggle the switch to Enabled to enable this analysis feature
5. To configure SecureAuth User Risk, click edit
User Risk Score
 |
6. Use the sliders or input values to configure the Risk Ranges for:
a. Minimum - 0 by default
b. Medium - 50 by default
c. High - 60 by default
d. Maximum - 100 by default
7. Click Save to preserve settings and to close the window
8. Under User Risk Score Actions, specify the action SecureAuth IdP will take if the user risk score falls within the specified range by making a selection from the dropdown (see Definitions for more information on actions)
a. High Risk - SecureAuth IdP will execute this action if the user risk score falls within the upper range
b. Medium Risk - SecureAuth IdP will execute this action if the user risk score falls within the middle range
c. Low Risk - SecureAuth IdP will execute this action if the user risk score falls within the lower range
d. Score Unavailable - SecureAuth IdP will execute this action if the user risk score cannot be retrieved
This action can occur if the user is not found in the data source or does not have a score assigned in the data source
See the KB article Unable to Communicate with the User Risk Adaptive Authentication Data Provider for more information if SecureAuth IdP is unable to communicate with the data source
9. (OPTIONAL) To add a new risk provider, click Add User Risk Score Provider – this step requires an on-premises risk score solution configured for use with SecureAuth IdP
Add New Risk Provider
|
9a. Configure the Risk Ranges for Minimum, Medium, High, and Maximum risk scores
9b. Under Connection Settings, enter the Risk Score Provider Name
9c. Enter the Base URL of the user risk solution instance in the format https://services.company.com:59
9d. Enter /api/user/{username}/info in the Get Profile Relative URL field
9e. Select the Authentication Method from the dropdown – i.e. Basic, OAuth 2.0, Cookie
9f. Enter a Username from the provider service account which can retrieve user profile information
9g. Provide the Password associated with the Username
9h. From the Risk Score User Identifier dropdown, select the field to store the user risk score – which is either the Authenticated User ID (default selection), or the directory Profile Field mapped to the Property on the Data page
Note
NOTE: If using an available Property to store the user risk score, REST must be selected as the Source, and {userInfo}{riskScore} entered in the corresponding Field
See the sample image showing the Phone 4 Property selected
|
Property selections available from the Risk Score User Identifier dropdown include:
Phone 1
Phone 2
Phone 3
Phone 4
Email 1
Email 2
Email 3
Email 4
Aux ID 1
Aux ID 2
Aux ID 3
Aux ID 4
Aux ID 5
Aux ID 6
Aux ID 7
Aux ID 8
Aux ID 9
Aux ID 10
9i. Enter {userInfo}{riskScore} in the Risk Score JSON Path used by the Risk Score User Identifier
9j. Click Save to preserve settings and to close the window
IP / Country Restriction
 |
10. In the IP / Country Restriction section, toggle the switch to Enabled to enable this analysis feature
11. Select Country Restriction from the Restriction Type dropdown to restrict access by country code(s); or select IP Restriction to restrict access by IP address(es)
12. Select Allow from the Country List / IP List dropdown to create a list of allowed country codes or IP addresses that can access the realm; or select Deny to create a list of country codes or IP addresses that cannot access the realm
13. Provide the list of country codes or IP addresses that are allowed or denied access to the realm
Notice
Country codes must be listed in two-letter ISO format
14. Select the appropriate action to take when an end-user attempts to gain access from a country code or IP address that is restricted from accessing the realm from the Failure Action dropdown
See Definitions for more information
15. Check Require user to enter username before adaptive authentication occurs if end-users are to provide the username before country or IP address analysis is conducted
SecureAuth Threat Service
Note
This feature requires a special SecureAuth IdP license that allows access to the SecureAuth Threat Service feature
Contact SecureAuth Support for more information or to upgrade
 |
16. In the SecureAuth Threat Service section, toggle the switch toEnabled to enable this analysis feature
17. Select the appropriate action to take when an end-user falls into a specific risk threshold from the Failure Action dropdown
See Definitions for more information on risk thresholds and failure action descriptions
18. Set the IP Whitelist to the IP addresses (comma-separated) that are automatically allowed
19. Check Require user to enter username before adaptive authentication occurs if end-users are required to provide a username before conducting the Threat Data analysis.
User / Group Restriction
 |
20. In the User / Group Restriction section, toggle the switch to Enabled to enable this analysis feature
21. Select User Restriction from the Restriction Type dropdown to restrict access by end-users; or select Group Restriction to restrict access by user groups
22. Select Allow from the User List or Group List dropdown to create a list of allowed end-users or groups that can access the realm; or select Deny to create a list of end-users or groups that cannot access the realm
23. Provide the list of end-users or user groups that are allowed or denied access to the realm
24. Select the action to be taken for end-users or user groups that are restricted from accessing the realm from the Failure Action dropdown
See Definitions for more information
Geo-velocity
 |
25. In the Geo-velocity section, toggle the switch to Enabled to enable this analysis feature
26. Set Set Velocity Limit to the miles-per-hour an end-user is allowed to travel without activating the Failure Action
27. Select the action to be taken from the Failure Action dropdown for end-users whose current location is not possible to reach based on the Set Velocity Limit and last access time and location
See Definitions for more information
Geo-velocity Calculations
Geo-velocity calculations are based on the Set Velocity Limit and compared to the location and time of the end-user's last successful login event
A violation occurs if the time span between the last successful login event and the current login attempt is less than the travel time between the two locations
The duration of a violation period is calculated based on the distance between the two locations divided by the Set Velocity Limit
During the violation period, unsuccessful login attempts are not stored, even if multiple Geo-velocity violations are detected
If the end-user successfully logs in within the velocity limit boundaries and if another violation is detected, the new violation period starts from the last successful login event
Example of Geo-velocity violations and successful logins for a Set Velocity Limit of 500mph
A. An end-user successfully logs in from Virginia, USA at 10:00 a.m. EST
B. At 10:15 a.m. EST, a violation from the UK is detected
Since the Set Velocity Limit is set at 500mph and the distance between the locations is about 3,500 miles, the violation period is valid for about 7 hours (3500 / 500) – i.e. until 5:15 p.m. EST
C. An hour later at 11:00 a.m. EST, the end-user in Virginia successfully logs in again
D. At 11:15 a.m. EST, another violation from the UK is detected
The violation period is valid until 6:00 p.m. EST, 7 hours from the last successful login event
E. At 6:15 p.m. EST, an end-user in the UK with valid credentials successfully logs in since the 7-hour violation period has passed
Note
In order to keep track of user access history, the "Access Histories" field of user profile needs to be enabled in the Web Admin Data tab, and writeable to the user store (LDAP, AD, etc.):
 |
See above for the required properties of the Access Histories directories field
Warning
Click Save once the configuration has been completed and before leaving the Adaptive Authentication page to avoid losing changes.
Tip
Contact SecureAuth Support to download the Adaptive Authentication Best Practices guide for additional information
(OPTIONAL) Redirect with Username Configuration Steps
Follow these optional configuration steps to redirect users to another SecureAuth IdP realm with the provided username
These steps are for the Redirect Failure Action and to enable end-users to log into the second realm without inputting their username once more
Note
This use case's configuration requires settings on the initial realm (Realm A) and the realm to which end-users are redirected (Realm B)
Adaptive Authentication
 |
1. On Realm A only, in the Adaptive Authentication section, select Redirect from the Failure Action dropdown
Notice
NOTE: This configuration can be completed in any of the five Adaptive Authentication policies
Shown as an example is the User / Group Restriction policy
2. In the new textbox, prepend RedirectWithToken.aspx?Target= to the realm URL, e.g. RedirectWithToken.aspx?Target=https://secureauth.company.com/secureauth2
Warning
Click Save once the configurations have been completed and before leaving the Adaptive Authentication page to avoid losing changes
Post Authentication
Note
The following steps are required for both Realm A and Realm B (the realm to which end-users are redirected from Realm A)
 |
3. In the Forms Auth / SSO Token section, click View and Configure Forms Auth Keys / SSO Token
Forms Authentication
 |
4. Set the Name to a unique, friendly token name
Machine Key
 |
5. Set the Validation Key and Decryption Key to the same values; or if no keys have been generated, then keep as the defaulted values
Authentication Cookies
 |
6. Set the Pre-Auth Cookie and Post-Auth Cookie to the same, unique token name set in step 4
Warning
Click Save once the configurations have been completed and before leaving the Token Settings page to avoid losing changes
Logging Features
Key-Value Pair Properties
Several key-value pair properties are placed in the structured data element of a syslog entry. These properties may also be logged in the header or message elements but are difficult to parse or extract.
Notice
NOTE: Not all properties introduced in these tables may appear in logs, since log data is set to show based on the SecureAuth Threat Service subscription level.
Threat Descriptions
Threat Types
The following values appear only in the realm's logs, and help to further classify the type of threat that is detected
Threat Categories
The following values appear only in the realm's logs, and help to further classify the type of threat that is detected