You can use the Country attribute in access policies to configure different authentication requirements for users who are located in different countries. You can:
- Allow or deny access to users in specified countries.
Require users to perform additional authentication using different assurance levels, depending on their country location.
Country Attribute Condition Examples
The following table shows sample conditions and results using the Country attribute.
|COUNTRY IS GERMANY ALLOW ACCESS||Users authenticating from Germany can use the application without additional authentication.|
|COUNTRY IS NOT GERMANY ALLOW ACCESS||Users authenticating from all countries except for Germany can use the application without additional authentication.|
|COUNTRY IS BRUNEI DENY ACCESS||Users authenticating from Brunei are denied access.|
|COUNTRY IS NOT BRUNEI DENY ACCESS||Users authenticating from all countries except Brunei are denied access.|
|COUNTRY IS FRANCE AUTHENTICATE ASSURANCE LEVEL LOW||Users authenticating from France must complete additional authentication using the Low assurance level.|
|COUNTRY IS FRANCE, SWEDEN, NORWAY AUTHENTICATE ASSURANCE LEVEL MEDIUM||Users authenticating from any listed country must complete additional authentication using the Medium assurance level.|
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.