SecureAuth IdP adds analysis into the authentication workflow to more effectively mitigate attacks and unauthorized users from gaining access into sensitive resources.
Adaptive Authentication in SecureAuth IdP v9.0.1 - v9.0.2 includes:
IP Address / Country Restriction: Restrict access by IP address(es) or country code(s)
IP Reputation and Threat Detection: Restrict access based on risk factors and threat intelligence by IP Address evaluation
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
User Risk: Restrict access based on user reputation and/or user behavior factors
Adaptive Authentication also provides Failure Actions, which tell SecureAuth IdP how to handle an end-user that does not meet the analysis requirements:
The specific Adaptive Engine check is not executed. The next step in Adaptive Engine is performed, or, if all Adaptive Authentication steps are completed, the end-user is taken through any additional configured workflow steps.
Workflow is stopped immediately...
Login request is blocked, thereby bypassing all workflows, remaining Adaptive Engine steps, and post authentication actions.
End-user is redirected to the URL provided in the field (e.g. another SecureAuth IdP realm)...
Adaptive Engine is exited and end-user is redirected to an alternate URL or realm to continue with an alternate workflow, thereby bypassing all workflows and remaining Adaptive Engine steps.
Step up auth
Additional authentication is required...
Adaptive Engine is exited and end-user continues through the workflow, bypassing the persistent token check such as Device Recognition / Fingerprint, Cookie or Certificate, and forcing 2-Factor Authentication as defined in the workflow.
Step down auth
End-user is taken to the next workflow step, bypassing additional analysis and any 2-Factor Authentication steps...
Adaptive Engine is exited and end-user bypasses remaining Adaptive Engine steps, persistent token check, and 2-Factor Authentication check. Most commonly, the end-user will be required to enter a password, provided the workflow is configured for this entry.
End-user is taken through any additional configured workflow steps (2-Factor Authentication), bypassing remaining analysis steps...
Adaptive Engine is exited and the next step in the workflow is performed such as a persistent token check or 2-Factor Authentication.
End-user is taken to the post-authentication target (IdM page, application, etc.), bypassing additional analysis and configured workflow steps...
Adaptive Engine is exited and end-user is taken to the post authentication target (such as Identity Management page or application), thereby bypassing all workflows and remaining Adaptive Engine steps, as well as a password check, if the workflow is configured for this entry.
See the Redirect with Username Configuration Steps section below for use case-specific configuration
1. Have SecureAuth IdP v9.0.1 - v9.0.2
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
5. (OPTIONAL) Have an on-premises Sailpoint IdentityIQ and / or Exabeam UEBA solution to utilize the User Risk analysis function
SecureAuth IdP Configuration Steps
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)
For JSON, these requirements must be met for the directory field that contains the Access Histories information:
Length: No limit / undefined
Data Type: DirectoryString
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 HistoriesProperty
Steps 2 - 3 are required if enabling Geo-velocity
The Properties must be mapped in each realm in which the User / Group Restriction and / or Geo-velocity analysis features are utilized
Click Save once the configurations have been completed and before leaving the Data page to avoid losing changes
Sorting Order enables the organization of the Adaptive Authentication functions to create a completely customized workflow
Each adaptive authentication factor that is enabled appears in the table, and admins can drag and drop to reorder the sequence in which they are processed
IP / Country
4. In the Adaptive Authentication section, under IP / Country, check Enable IP / Country Restriction to enable this analysis feature
5. 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)
6. 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
7. Provide the list of country codes or IP addresses (based on the selection in step 5) that are allowed or denied access to the realm (based on the selection in step 6)
13. Check Require user to enter username before adaptive authentication occurs if end-users are required to provide a username before conducting the IP Reputation/Threat Data analysis.
User / Group
14. Check Enable User / Group Restriction to enable this analysis feature
15. Select User Restriction from the Restriction Type dropdown to restrict access by end-users; or select Group Restriction to restrict access by user groups
16. Select Allow from the User List or Group List (based on the selection in step 15) 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
17. Provide the list of end-users or user groups (based on the selection in step 15) that are allowed or denied access to the realm (based on the selection in step 16)
18. Select the action to be taken for end-users or user groups that are restricted from accessing the realm from the Failure Action dropdown
22. Check Enable User Risk to enable this analysis feature
23. In the From field of each risk level (High, Medium, Low), enter the User Risk score (retrieved from Exabeam or Sailpoint) that will trigger the Action for that level
24. In the Action dropdown for each risk level (High, Medium, Low), configure the action to be taken when the User Risk score of an end-user falls within the specified range (see Definitions for more information on actions)
25. In the No Score Returned field, configure the action to take when the Adaptive Authentication engine is unable to retrieve an end-user's risk score
(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
This use case's configuration requires settings on the initial realm (Realm A) and the realm to which end-users are redirected (Realm B)
1. In Realm Aonly, in the Adaptive Authentication section, select Redirect from the Failure Action dropdown
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
Click Save once the configurations have been completed and before leaving the Adaptive Authentication page to avoid losing changes
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
4. Set the Name to a unique, friendly token name
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
6. Set the Pre-Auth Cookie and Post-Auth Cookie to the same, unique token name set in step 4
Click Save once the configurations have been completed and before leaving the Token Settings page to avoid losing changes
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.
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 Type identifies the classification of the attack.
Continent identifies the location of the IP address: Africa, Antarctica, Asia, Australia, Europe, North America, Oceania (Melanesia, Micronesia, Polynesia), South America.
Full country name is used within the ISO-3166Alpha-2 code system.
International Standard Organization's 2-letter code corresponds to the name of the country, as defined in ISO-3166.
Country Confidence Factor – from 0 (null) to 99 – reflects a relative measure of certainty the user is in the location identified in the country field. The higher the value, the greater the likelihood that the user is in the assigned country.
Directional Region information (e.g. 'northwest') for some countries, or specific regional information (e.g. 'northern_ireland') for a few other countries. Region information is currently available for the U.S., U.K., Brazil, Denmark, France, Philippines, Belgium, Burkina Faso, Equatorial Guinea, Greece, Guinea, Indonesia, Ireland, Italy, Malawi, Marshall Islands, New Zealand, Slovenia, Spain, Sri Lanka, and Uganda.
IP Intelligence provides information for states and provinces (i.e. first-level administrative division) in all countries where they exist.
NOTE: IP Intelligence uses the localized spelling for state values. For example, the state of Tuscany in Italy is identified as ‘toscana’ in GeoPoint data. This approach ensures the highest degree of system compatibility, as well as the ability to use localized state names for customer applications serving those countries.
State Code is the abbreviated code that identifies a state or province.
IP Intelligence provides a State Confidence Factor that reflects a relative measure of certainty that the user is in the location identified in the state field. Values range from 0 (null) to 99. The higher the value, the greater the likelihood that the user is in the assigned state.
IP Intelligence locates users in respective cites and recognizes more than 150,000 distinct international locations.
NOTE: IP Intelligence uses the localized spelling for city values. For example, the city of Rome in Italy is identified as ‘roma’ in GeoPoint data. This approach ensures the highest degree of system compatibility, as well as the ability to use localized state names for customer applications serving those countries.
IP Intelligence provides a City Confidence Factor that reflects a relative measure of certainty that the user is in the location identified in the city field. Values range from 0 (null) to 99. The higher the value, the greater the likelihood that the user is in the assigned city.
Postal Code is assigned to a corresponding city. Most of GeoPoint’s postal code assignments are derived from the city field. Where there is sufficient evidence, the postal code is explicit. IP Intelligence provides postal codes for most countries.
Area Code is the phone number prefix assigned to its corresponding city. Prefixes are available in the U.S., Canada, and selectively in other countries.
NOTE: 'area_code' does not include the telephone country code.
Time Zone is provided as a +/- offset of Greenwich Mean Time (GMT) and is represented as a floating point number so that calculations can be made for a specific time in a designated location. Values can be between -11 and 13. The time zone is derived from the city field, if known, or from the country field if the city is unknown. If city is unassigned and the country spans multiple time zones, a value of ‘999’ is returned.
Latitude of the identified GeoPoint location is expressed as a floating point number with range of -90 to 90. Positive numbers represent North and negative numbers represent South. Latitude and longitude are derived from the city or postal code.
Longitude of the identified GeoPoint location is expressed as a floating point number with range of -180 to 180. Positive numbers represent East and negative numbers represent West. Latitude and longitude are derived from the city or postal code.
Defined Market Area (DMA) codes are assigned to geographical regions in the U.S. where the population typically receives similar media: e.g. radio, television, newspapers, and the Internet. The code, which is based on Nielsen's market codes but has parity with Google's metropolitan area codes, defines geographical areas that may coincide and overlap with one or more metropolitan regions. For example, San Francisco, San Jose, and Oakland all fall into the same DMA.
Metropolitan Statistical Area (MSA) codes represent geographical boundaries of U.S. counties or towns that use Core-Based Statistical Areas (CBSAs) defined by the U.S. Office of Management and Budget (OMB) from data gathered by the U.S. Census Bureau.
Connection Type pertains to ways in which users can connect to the Internet: fiber optic connections, leased line, high-speed or broadband, frame relay circuits, DSL, cable modem broadband circuits, Integrated Services Digital Network, dial-up modem, fixed wireless connections, cellular network providers, and unknown means.
Connection speed to the Internet is divided into categories of high, medium, or low, as determined by the Connection Type.
IP Routing Type (IPRT) specifies how the connection is routed through the Internet and can be used to determine how close the user is to the public IP address. For example, a user connecting through a fixed connection is likely very close to the connection. A user connecting through a regional proxy is probably in the same country as the connection, whereas a user connecting through a satellite connection could be anywhere.
Autonomous System Number (ASN) is a globally unique number assigned to a group of networks administered by a single entity such as a Network Service Provider (NSP) or a very large organization. ASNs manage data routing via the Border Gateway Protocol (BGP). IP Intelligence provides ASN information in 32-bit integer format.
Second-Level Domain (SLD) is the part of the domain name that precedes the top-level domain. E.g. in www.companyname.com, “companyname” is the second-level domain.
Top-Level Domain (TLD) identifies the most general part of the domain name in a Web address. Common top-level domains include com, net, edu (educational), mil (military), as well as country codes like jp (Japan) and fr (France).
The Registering Organization is the entity responsible for the actions and content associated with a given block of IP addresses. This function is in contrast to that of the carrier, which is responsible for routing traffic for network blocks. Registering Organizations include many types of entities, including corporate, government, or educational entities, and ISPs managing the allocation and use of network blocks.
Carrier provides the name of the organization that owns the ASN and is responsible for traffic flowing on the network or set of networks designated as an Autonomous System (AS) and identified by the ASN. While there are more than 27,000 active ASNs, there are fewer carriers, because a single carrier often manages several ASNs.
A status is assigned to an IP address detected as a proxy and indicates the IP address may be associated with an anonymizing proxy. The status is a relative indicator of how recent the proxy was found to be active and the proxy’s category.
Proxy Level describes the degree of concealment for the end user via use of the proxy: e.g. obfuscation of the user’s originating IP address. Levels of obfuscation include: transparent, anonymous, distorting and elite.
Proxy Type describes the network or protocol used by the server to proxy the user connection. Classifications include the use of HTTP, Tor, Web and SOCKS.
Proxy Last Detected provides the most recent date on which IP Intelligence proxy detection technology confirmed the proxy was active or served as a private proxy. This information supplies more granular proof that an IP address may be associated with an anonymizing proxy.
Hosting Facility identifies whether the connection originated at a facility that provides storage, computing or telecommunication services. The designation of a 'hosting_facility' includes the following type of service providers: colocation, cloud computing, dedicated hosting, virtual private servers and Web hosting.
Risk Score is based on IP Address evaluation and threat intelligence data.
Applicable only to IP reputation log entries. Also logged in the message element.