An access policy can specify conditions to restrict user access based on whether users match the conditions you define. You can also require different authentication methods for users who match certain conditions.
For example, you can require different authentication methods for users with unknown browsers or who are located in certain countries. You can require all users from a specific IP address to authenticate at a High assurance level, or users who authenticate with Chrome to authenticate with a Low assurance level.
You can add conditions that allow users to skip additional authentication if they used the same browser previously in a successful authentication, or if they are authenticating from a country on an approved list, or if they access the application portal using an LDAP password.
You can also use conditions to deny access to a subset of your target population. For example, you can allow access to all users in the specified LDAP directory server, while denying access only to users who are located in certain countries.
Note: RADIUS clients cannot use access policies that contain authentication conditions.
Supported Condition Attributes for Access Policies
RSA SecurID Access supports the following condition attributes in access policies.
|Identity Confidence Attribute|| |
Leverages machine-learning algorithms to profile the user's normal activity in order to understand deviation from that activity in the current authentication request. The attribute allows RSA SecurID Access to establish high or low confidence in a user's identity based on data it has collected about the user over a period of time.
|Known Browser Attribute||Allows you to configure different authentication requirements for access requests coming from known and unknown browsers.|
|Country Attribute||Allows you to make it easier for users from countries that are trusted to access protected resources.|
|Trusted Location Attribute||Allows you to make it easier for users from trusted locations to access protected resources.|
|Trusted Network Attribute||An IP address or range of addresses that can be used to ensure that only users from specific networks are allowed or denied access to applications and the application portal. They can also ensure that users located in specific networks are challenged using a designated assurance level for additional authentication.|
|Authentication Source|| |
Identifies the identity source or identity provider (IdP) used to validate the user's identity when accessing the application.
|Authentication Type|| |
The method used to sign in to the identity router, depending on whether users gain access through their identity source password, or Integrated Windows Authentication (SAML for IWA or SAML IdP).
|IP Address|| |
The user's IP address as seen by the identity router. Use this attribute for users who are inside your corporate network.
|User Agent|| |
Identifies the user's web browser type. You can use this attribute to differentiate between mobile browser users and desktop browser users.
To add an access policy, see Add an Access Policy.
The Cloud Authentication Service can establish high or low confidence in a user's identity based on data it collects when users attempt to authenticate over a period of time. You can configure authentication requirements for an application, or allow or deny access, based on identity confidence by using the Identity Confidence attribute in an access policy.
Understanding Identity Confidence
During data collection, the Cloud Authentication Service learns the following attributes about users.
|Time||Time at which an application is accessed.|
|Weekend||Whether or not the user authenticated during the weekend.|
|Uncommon Applications||User authenticates to an application that he normally does not access.|
|High Authentication Velocity||User unsuccessfully authenticates quickly numerous times.|
|New Device||User accesses a device he has never used before.|
|Location||Physical location of a user (estimated from IP address and HTML5 Geolocation).|
|High Device Access Rate||A user account is being used simultaneously on at least two devices.|
|Users on Device Velocity||Multiple users authenticating from the same device.|
|Users on IP Velocity||Multiple users authenticating from the same IP address.|
The identity confidence attribute leverages machine-learning algorithms to profile the user’s normal activity in order to understand deviation from that activity in the current authentication request. The identity confidence attribute evaluates the individual user, total population, and known risky authentication patterns to determine the identity confidence score. Older historical events are weighted less than more recent events, so past behavior ages out of the system and new behavior is more impactful.
Every time a user authenticates, the Cloud Authentication Service uses the data it has collected over time to calculate an identity confidence score and categorizes the score as high or low confidence. High confidence means the Cloud Authentication Service has high confidence that the user is indeed who he says he is. Low confidence means the Cloud Authentication Service cannot identify the user with a reasonable degree of certainty. In this case, you can deny the user access or require the user to authenticate at a higher assurance level.
Getting Started with Identity Confidence
The Cloud Authentication Service requires a learning period of at least 1,000 authentications (authentication minimum) to have sufficient user population history to optimize identity confidence scoring. Prior to the authentication minimum, the system sets a lower threshold for determining identity confidence. It is likely that more users will receive low confidence scores in this scenario. After the authentication minimum has been reached, the threshold will move up or down to optimize the low confidence scores. RSA recommends that you require multifactor authentication for all users until the system has reached the minimum authentication threshold. Additionally, most of your intended user population should be enrolled and using the service before removing the multifactor requirement.
The collected data is specific to your company. Data from a large user population collected over a long period of time ensures more reliable results than data from a small user population collected over a short period of time. Identity confidence results can vary from company to company depending on these factors.
Note: By default, data collection is enabled for your company. To obtain the maximum benefit from identity confidence scores, RSA recommends that you leave data collection enabled. If you need to disable or re-enable it, contact RSA Customer Support.
You can configure different authentication requirements for access requests coming from known and unknown browsers.
A browser becomes "known" when a user successfully completes additional authentication using a method such as Approve and clicks Remember This Browser. RSA SecurID Access "remembers" the browser the next time the user uses it to access the same resource. The access policy might allow a user with a known browser to skip additional authentication, or to use additional authentication with a lower assurance level. If the user does not click Remember This Browser, the browser is not known and different authentication requirements may apply, or the user may be denied access.
Note: Clicking Remember This Browser simplifies future authentication for a user only if you use the Known Browser attribute in an access policy.
If RSA SecurID Access cannot determine whether a browser is known, it assumes the browser is unknown. For example, if the condition is KNOWN BROWSER TRUE ALLOW ACCESS and the identity router cannot communicate with the Cloud Authentication Service to determine if the browser is known, RSA SecurID Access assumes the browser is unknown.
Browsers can reside on a mobile phone, tablet, desktop computer, or laptop. A user can remember one or more browsers running on a mobile device, regardless of whether the mobile device itself is registered with RSA SecurID Access.
Using the Country attribute in access policies can make it easier for users from countries that are trusted to access protected resources. For example, users in trusted countries might be allowed access without additional authentication, or be allowed to authenticate at a low assurance level, while users in other countries can be denied access or required to authenticate at higher assurance levels. For more information, see:
- Usage Guidelines for the Country and Trusted Location Attributes
- Example Country Attribute Conditional Expressions
- How Location is Collected for the Country and Trusted Location Attributes
Use the Trusted Location attribute in access policies to make it easier for users from trusted locations to access protected resources. For example, users in trusted locations might be allowed access without additional authentication, or be required to authenticate at a low assurance level, while users in other locations can be denied access or required to authenticate at higher assurance levels.
A trusted location is a specific address or a set of latitude/longitude coordinates with a radius of up to 1000 miles or kilometers, irrespective of national borders. You define a list of trusted locations in RSA SecurID Access. During authentication, RSA SecurID Access compares the user's location to all locations in this list and takes the appropriate action depending on whether a match is found.
Note: Use the Trusted Location attribute for users who are outside your corporate network. Use the IP Address attribute for users who are inside the corporate network.
Depending on browser configurations, your users might be prompted by the browser to allow location collection each time they complete authentication. To prevent these browser prompts, see Configure Browsers to Trust the Cloud Authentication Service.
For more information, see:
- Trusted Location Attribute Example
- Resolving Trusted Location When the User's Location is Unknown
- Setting Up Trusted Locations
- Usage Guidelines for the Country and Trusted Location Attributes
- Example Trusted Location Conditional Expressions
- How Location is Collected for the Country and Trusted Location Attributes
Suppose the Trusted Locations list for your deployment contains the following locations:
- London Office (radius 30 kilometers)
- San Francisco Office (radius 20 miles)
The access policy contains the following conditions:
|Trusted Location||True||Allow Access|
|Trusted Location||False||Authenticate High|
If a user authenticates from a location that is 10 kilometers from the London Office, then the user is at a trusted location (Trusted Location = True) and the user can open the application without additional authentication. If a user authenticates from a location that is 25 miles from the San Francisco Office, then the user is not at a trusted location (Trusted Location = False) and the user must authenticate at the High assurance level.
If HTML5 geolocation information is not available to evaluate the trusted location attribute, in all cases RSA SecurID Access resolves the location as "not trusted" and behaves as described in the following table.
|Possible Conditions||Behavior When the User's Location is Unknown and Location is Resolved as Not Trusted|
|Location is trusted <action>||RSA SecurID Access evaluates the next condition statement in the rule set.|
|Location is trusted AND <attribute> <operator> <value> <action>||The entire condition is false. Any expressions after AND are not evaluated. RSA SecurID Access evaluates the next condition statement in the rule set.|
|Location is trusted OR <attribute> <operator> <value> <action>||RSA SecurID Access reads any expressions after OR and then evaluates the next condition statement in the rule set.|
|Location is not trusted <action>||RSA SecurID Access performs the action defined for the condition.|
|Location is not trusted AND/OR <attribute><operator> <value> <action>||RSA SecurID Access reads any expressions after AND or OR and then evaluates the next condition statement in the rule set.|
Setting up trusted locations involves these steps:
- Define a list of trusted locations on the Trusted Locations page at Policies > Trusted Locations. See Add a Trusted Location.
- Add conditions to your access policies to include Trusted Location attributes. See Add an Access Policy.
For best results, follow these guidelines when using the Country or Trusted Location attributes.
- Use the Country and Trusted Location attributes in conditions with other attributes. Do not rely solely on either attribute to allow or deny access.
- Define at least one "fallback" attribute after Country or Trusted Location in the condition list to resolve access if the user's country or location cannot be determined.
- Do not use Country as an attribute in the fallback condition.
- You can use Trusted Location = False, with other attributes, in the fallback condition.
These guidelines are important for the following reasons:
- If RSA SecurID Access cannot resolve the location through HTML geolocation or any other means, and if Country or Trusted Location is the only condition used, users are denied access.
- If a malicious intruder attempts to gain access by spoofing the HTML geolocation, an additional condition can filter out this user and deny access.
All rule sets have a condition called No Matching Condition at the bottom of the condition list. This condition is used if the previous conditions are not matched. By default, No Matching Condition denies access to all users, but you can modify the Action field to allow access or to require additional authentication. You can use No Matching Condition as the fallback condition, or you can add a fallback condition using an attribute.
For example, consider these conditional expressions that use the Country attribute:
AUTHENTICATION SOURCE IS CNDA01 AND COUNTRY IS CANADA, AUTHENTICATE LOW
COUNTRY IS NOT CANADA DENY ACCESS
IP ADDRESS CONTAINS 222.222 AUTHENTICATE HIGH
As a result of these conditional expressions, users in the CNDA01 identity source in Canada can authenticate at the Low assurance level. Users outside Canada are denied access. If RSA SecurID Access cannot determine the country through HTML geolocation, users in the specified network must authenticate at high assurance level. All other users are denied access.
Consider these example conditional expressions using Trusted Location:
AUTHENTICATION SOURCE IS CNDA01 AND TRUSTED LOCATION IS TRUE, AUTHENTICATE LOW
TRUSTED LOCATION IS FALSE DENY ACCESS
As a result of these conditional expressions, users in a trusted location from the authentication source CNDA01 can authenticate at the Low assurance level. Users in untrusted locations are denied access. If RSA SecurID Access cannot determine the country through HTML geolocation, Trusted Location is evaluated as false (untrusted) and the user is denied access.
When you use the country or trusted location attribute in a policy that is associated with an application or authentication client, all users in your deployment are prompted for permission to share their location when they open the application. When users click an application icon, RSA SecurID Access evaluates the attributes to determine who is allowed to open the application and what, if any, further authentication is required.
If you use the Portal Multifactor Authentication Policy to protect the application portal, users are prompted for permission to share location when they sign in to the portal.
Note: RSA SecurID Access uses HTML5 geolocation and can collect users' location only if the users' browsers allow access to external location resolution services.
If a user denies permission, the browser does not collect the location. As a result, a user might be denied access to certain applications, or might be asked to use a different authentication method. Some browsers will not prompt the user again. To re-enable collection at a later time, a user might need to modify the browser settings. You might need to instruct users on browser configuration.
Note: If your company uses a custom portal, see the RSA SecurID Access Custom Web Portal Developer's Guide for code examples that can help you build a portal that uses HTML5 geolocation to collect the location.