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.
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 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.
Evaluating Identity Confidence
The Cloud Authentication Service 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.
The user's identity confidence score is categorized as high or low confidence in relation to the Confidence Threshold. The Confidence Threshold is calculated based on information collected from all users within your company.
The Cloud Authentication Service requires an initial learning period of at least 1,000 authentications (authentication minimum) to collect sufficient user history to optimize identity confidence scoring. Prior to reaching the authentication minimum, the system uses a default threshold (0.37) for determining identity confidence. It is likely that more users will receive low confidence scores in this scenario. After this minimum has been reached, the Cloud Authentication Service adjusts the threshold up or down on a daily basis as it learns each user's behavior to optimize the low confidence scores.
RSA recommends that you require multifactor authentication for all users until the system has reached the minimum number of authentications.
The following table summarizes what high and low scores represent in relation to the Confidence Threshold.
|User's Overall Confidence Score||Meaning|
|Low score (low confidence)||A score that is lower than the Confidence Threshold indicates low confidence (high risk). This means the Cloud Authentication Service cannot identify the user with a reasonable degree of certainty. You can choose to deny the user access to protected resources or require the user to authenticate at a higher assurance level.|
|High score (high confidence)||A score that exceeds the Confidence Threshold indicates high confidence (low risk). This means the Cloud Authentication Service has high confidence that the user is indeed who he says he is.|
The Cloud Authentication Service reports detailed information about users' identity confidence scores. You can view this information in the Cloud Administration Console:
The User Event Monitor reports the following information in the Authentication Details column for event 25001.
|Confidence Details Reported in User Event Monitor||Description|
The user's overall identity confidence score, which is influenced by the user's separate scores for Device Confidence, Behavior Confidence, and Location Confidence.
|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. The initial default threshold is 0.37. After at least 1,000 authentications have been reached, the threshold is updated daily.|
Level of confidence based on attributes associated with the user's device. These attributes describe device characteristics and user behavior. The Device Confidence 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.
|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.|
|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.|
|Contributing Factors|| |
If a user's overall Confidence score indicates low confidence, the User Event Monitor reports up to four factors that most contributed to lowering the score. These factors are listed as Contributing Factors, in order from most impactful to less impactful. Factors that contribute to raising a user's overall score are not listed. For example:
In this example, the factors numbered 1, 2, 3, and 4 most contributed to lowering the user's overall Confidence score.
You can generate a report that displays 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 view information 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.
| || |
The total count includes attempts when users satisfy policy conditions that allow them to skip multifactor authentication.
| ||The confidence threshold determines if an evaluation results in high or low confidence.|
|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.
We want your feedback on this feature. Tell us what you think.
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 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, the browser is treated as unknown.
If the Cloud Authentication Service 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, the browser is treated as unknown.
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.