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.
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, Clone, or Delete 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.
You can use the Known Browser attribute to configure different authentication requirements for access requests coming from known and unknown browsers. Browsers can reside on a mobile phone, tablet, desktop computer, or laptop. The Cloud Authentication Service can remember one or more browsers running on a mobile device, regardless of whether the mobile device itself is registered with RSA SecurID Access.
Remember This Browser Prompt
During authentication, users are prompted to click the prompt Remember This Browser. This option has the following impact.
|The user clicks Remember This Browser and successfully completes additional authentication.||The next time the user attempts to access the same resource, the Cloud Authentication Service "remembers" the browser and applies the condition defined in the policy for known browsers. The user might be permitted to skip additional authentication or to authenticate with a lower assurance level.|
|The user does not click Remember This Browser.|
Omitting the Known Browser Attribute From an Access Policy
If you do not use the Known Browser attribute in an access policy, the browser cannot become known and authentication is unaffected by this condition.
Disabling the Remember This Browser Prompt
Disabling the Remember This Browser prompt has the following impact:
Users are never prompted to click Remember This Browser during authentication.
The Cloud Authentication Service ignores the Known Browser attribute in access policies and always assumes the browser is unknown, even if it was previously "known."
For instructions on disabling the prompt, see Configure Company Information and Certificates.
Undetermined Browser Status
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 or Delete a Trusted Location.
Add conditions to your access policies to include Trusted Location attributes. See Add, Clone, or Delete 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.