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.
To add condition attributes to an access policy, see Add an Access Policy.
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).
The user's IP address. 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.
|High-Risk User List|| |
Identifies a user account that might be compromised, or one in which suspicious user account activity has been detected by a third-party program such as RSA NetWitness.
To add an access policy, see Add an Access Policy.
Note: If your deployment is downgraded from Premium Edition to Enterprise Edition, you must examine your access policies and edit them if necessary to ensure that they comply with the Enterprise Edition license. Policies that are not up-to-date can result in authentication failures.
Detecting the IP Address for Condition Attributes
The trusted network attribute and the IP address attribute require RSA SecurID Access to detect the user's IP address. This is accomplished in different ways for different deployments. When users are accessing an application or portal that is protected by the SSO Agent configuration, the identity router detects either the user’s private IP address, or the gateway IP address between the user and the identity router. For end-users accessing a protected resource integrated through a relying party configuration or My Page, the Cloud Authentication Service detects the public/NAT gateway IP. This is typically the same IP address that would be reported in an internet search for “what is my IP address?” The Cloud Authentication Service does not see the user’s private IP address because the service is outside your corporate network.
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.
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.
Disabling Identity Confidence Data Collection
RSA recommends that you leave data collection for identity confidence and location enabled. If your company requires you to disable data collection for identity confidence, do not use the identity confidence attribute in access policies. To obtain maximum benefit from identity confidence scores, RSA recommends that you also leave location data collection enabled. If you must disable data collection, see Configure Company Information and Certificates for instructions.
You can view detailed information about authentication attempts for which the Cloud Authentication Service evaluates access policies containing the identity confidence attribute:
The User Event Monitor reports the following information in the Details column for event 25001 each time a user authenticates and the identity confidence score is evaluated. All of the attributes described in Understanding Identity Confidence affect these scores.
|User Event Message Detail||Description|
|confidence||The user's overall identity confidence score, which is influenced by the user's separate scores for deviceConfidence, behaviorConfidence, and locationConfidence.|
|confidenceThreshold||Confidence scores higher than this threshold indicate high confidence, while lower scores indicate low confidence. The threshold calculation is based on information collected from all users within your company and adjusts over time as the Cloud Authentication Service learns about your users and as more users authenticate. After at least 1,000 authentications have been reached, the threshold is updated daily.|
|deviceConfidence||Level of confidence based on attributes associated with the user's device. These attributes describe device characteristics and user behavior. The deviceConfidence score starts at 0.0 if the user has not previously used the device and increases each time the user successfully authenticates from the same device.|
|behaviorConfidence||Level of confidence based on attributes associated with the user's behavior. For example, this score is adjusted when the user successfully authenticates to access the same application within the same timeframe.|
|locationConfidence||Level of confidence based on attributes associated with the user's location. For example, this score is increased if the user successfully authenticates from the same location every day and decreased if the user successfully authenticates from different locations every day.|
You can generate a report to display the number of times users attempted to access resources that are protected by access policies that contain the identity confidence attribute. To view this information, click Access > Identity Confidence Analytics. You can obtain a report for all users in your company or for individual users within a specified timeframe.
Note: The search criteria must be able to return at least one authentication attempt in which identity confidence was evaluated. Otherwise, no attempts are displayed.
We want your feedback on this feature. Tell us what you think.
Number of authentication attempts to access resources protected by access policies that include the identity confidence attribute.
At least one attempt must be found to display results on this page.
The total count includes attempts when users satisfy policy conditions that allow them to skip multifactor authentication.
Number of authentication attempts to resources protected by access policies that do not include the identity confidence attribute.
Number of authentication attempts that resulted in a high confidence score
|The confidence threshold determines if an evaluation results in high or low confidence.|
|Number of authentication attempts that resulted in a low confidence score|
|Reasons for low confidence scores|| |
A low confidence score occurs when the Cloud Authentication Service does not recognize the user's behavior, device, or location in an authentication attempt because the user has changed behavior, device, or location since the previous attempt. Or the score may be low if the user is new and has not authenticated enough times to earn a high confidence score. Low confidence can be due to one or more of these factors:
Undetermined cause is reported when the Cloud Authentication Service cannot identify a single factor as the predominant cause of the low score. Multiple factors always play a role in confidence scores, and sometimes one particular factor does not stand out.
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:
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:
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.
Users may be prompted for permission to share their location at the following times:
When users click an application icon after signing in to the application portal, location may be collected when the access policy is evaluated. If the authentication request is from a relying party through SAML, location may be collected before the user completes additional authentication.
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. If you do not enable the policy, location is not collected during portal access.
Administrators may be prompted to share location when they open the Cloud Administration Console.
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.
Disabling Location Data Collection
RSA recommends that you leave data collection for location enabled. If your company requires you to disable data collection, the Cloud Authentication Service does not collect HTML5 location data from users during authentication. When disabled, do not use the Trusted Location attribute in access policies. Also, when disabled, location calculations for the Country attribute are less accurate. If you must disable data collection, see Configure Company Information and Certificates for instructions.