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. Users who authenticate from a location that is not trusted can be denied access to an application, or required to perform step-up authentication at higher assurance levels.
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.
Trusted Location Attribute Example
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.
Trusted Location Attribute Usage Guidelines
For best results, use the Trusted Location attribute in rule sets with multiple conditions. Do not rely solely on the Trusted Location attribute to allow access. If a malicious intruder spoofs the HTML geolocation, using multiple conditions can prevent that user from gaining unauthorized access. If RSA SecurID Access cannot resolve the HTML geolocation and Trusted Location is the only condition used, users are denied access.
The following table shows examples of preferred usage.
|Trusted Location Condition Example Rule Sets||Result|
AUTHENTICATION SOURCE IS CNDA01 AND TRUSTED LOCATION IS TRUE, AUTHENTICATE LOW
TRUSTED LOCATION IS FALSE DENY ACCESS
|Users in a trusted location from the authentication source CNDA01 can authenticate at the lowest 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.|
IDENTITY CONFIDENCE IS HIGH AND TRUSTED LOCATION IS TRUE, ALLOW ACCESS
TRUSTED LOCATION IS FALSE DENY ACCESS
|Users with a high identity confidence score and who are in a trusted location can access the resource without additional authentication. Users in untrusted locations are denied access. If the location cannot be determined through HTML geolocation, Trusted Location is evaluated as false (untrusted) and the user is denied access.|
Setting Up Trusted Locations
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.
How Location is Collected for the Country and Trusted Location Attributes
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.
Handling an Unresolved Country or Trusted Location
If HTML5 geolocation information is not available to evaluate the country attribute, RSA SecurID Access might still be able to determine the user’s location through other means. If the country cannot be determined, RSA SecurID Access ignores the condition and evaluates the next condition in the rule set.
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 RSA SecurID Access behaves as described in the following table.
|Location is trusted <action>||The location is not trusted. RSA SecurID Access evaluates the next condition statement in the rule set.|
|Location is trusted AND <attribute> <operator> <value> <action>||Location is not trusted. The entire condition is false. Any expressions after AND are not evaluated.|
|Location is trusted OR <attribute> <operator> <value> <action>||Location is not trusted. RSA SecurID Access reads any expressions after OR and evaluates the entire condition statement.|
|Location is not trusted <action>||Location is not trusted and RSA SecurID Access performs the action defined for the condition.|
|Location is not trusted AND/OR <attribute><operator> <value> <action>||Location is not trusted. RSA SecurID Access reads any expressions after AND or OR and evaluates the entire condition statement.|
Fallback Conditions for Country and Trusted Location
RSA recommends that when you use the country or trusted location attributes, you also add a fallback condition to use when RSA SecurID Access cannot determine the location. This condition must appear in the list after the country or trusted location conditions in the rule set.
For example, suppose a rule set contains the following conditions:
- Location is Trusted Allow Access
- Country is Canada Authenticate Low
- Unknown Browser Authenticate High
If RSA SecurID Access cannot determine the user's location, it evaluates the first condition as "not trusted," skips the second condition, and evaluates the third "fallback" condition.
When adding a fallback condition, observe these guidelines:
- Do not use the country attribute in the fallback condition. Instead, you might use a different attribute and require users to authenticate with the High assurance level.
- You can use trusted location in a fallback condition. For example, the first condition can be Location is Trusted Allow Access, and the fallback condition can be Location is Not Trusted Authenticate with a High assurance level.
All rule sets have a default condition called No Matching Condition at the bottom of the condition list. This condition is used if the context of the user request does not match any of the previous conditions. By default, No Matching Condition denies access to all users, but you can modify the Action field to allow access or to require step-up authentication. You can use No Matching Condition as the fallback condition, or you can add a fallback condition using an attribute.