Trusted Location Attribute for Authentication Conditions

Document created by RSA Information Design and Development on Oct 7, 2016Last modified by RSA Information Design and Development on Sep 15, 2017
Version 6Show Document
  • View in full screen mode

You can use the Trusted Location attribute in access policies to determine authentication requirements based on whether users are authenticating from a predefined trusted location.

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.

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

For 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:

                       
AttributeValueAction
Trusted LocationTrueAllow Access
Trusted LocationFalseAuthenticate 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.

Setting Up Trusted Locations

Setting up trusted locations involves these steps:

  1. Define a list of trusted locations on the Trusted Locations page at Policies > Trusted Locations. See Add a Trusted Location.
  2. 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.

                               
ConditionsResult
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.

 

 

You are here
Table of Contents > Access Policies > Trusted Location Attribute for Authentication Conditions

Attachments

    Outcomes