Use the Country attribute in access policies to 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 required to authenticate at a low assurance level, while users in other countries can be denied access or required to authenticate at higher assurance levels.
Country Attribute Usage Guidelines
For best results, use the Country attribute in rule sets with multiple conditions. Do not rely solely on the Country attribute to allow or deny access. There are two reasons for this:
- If RSA SecurID Access cannot resolve the HTML geolocation and Country is the only condition used, users are denied access. You need an additional condition attribute at the end of the condition list to resolve 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.
The following table shows examples of preferred usage.
|Country Condition Example Rule Sets||Result|
AUTHENTICATION SOURCE IS CNDA01 AND COUNTRY IS CANADA, AUTHENTICATE LOW
COUNTRY IS NOT CANADA DENY ACCESS
IP ADDRESS CONTAINS 222.222 AUTHENTICATE HIGH
|Users in the specified identity source in Canada can authenticate at the lowest 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.|
IDENTITY CONFIDENCE IS HIGH AND COUNTRY IS GERMANY ALLOW ACCESS
COUNTRY IS NOT GERMANY DENY ACCESS
AUTHENTICATION SOURCE CONTAINS CORPAD2AUTHENTICATE HIGH
|Users with a high identity confidence score and who are from Germany can access the resource without additional authentication. Users outside Germany are denied access. If the country cannot be determined through HTML geolocation, users who are authenticating from the IdP Corp AD2 must authenticate at high assurance level. All other users are denied access.|
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.