Condition Attributes for Access Policies

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

SecurID supports the following condition attributes in access policies.

Attribute Purpose

Identity Confidence

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 SecurID 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).

IP Address

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

To add an access policy, see Add, Clone, or Delete an Access Policy.

Note: If your deployment is downgraded from Cloud Premier to Cloud Plus, you must examine your access policies and edit them if necessary to ensure that they comply with the Cloud Plus 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 SecurID 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 IDR 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.

Known Browser Attribute

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

Remember This Browser Prompt

During authentication, users are prompted to click the prompt Remember This Browser. This option has the following impact.

Event Result
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.

The browser does not become "known" and the Cloud Authentication Service applies the authentication requirements for unknown browsers. The user may be required to authenticate at a higher assurance level or be denied access.

A known browser is deleted from the user's account after it has not been used for 90 days. Users who do not use a known browser within 90 days might have to reauthenticate.

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.

Country Attribute

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:

Trusted Location Attribute

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 SecurID. During authentication, SecurID 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:

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:

Attribute Value Action
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.

Resolving Trusted Location When the User's Location is Unknown

If HTML5 geolocation information is not available to evaluate the trusted location attribute, in all cases SecurID 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> SecurID 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. SecurID evaluates the next condition statement in the rule set.
Location is trusted OR <attribute> <operator> <value> <action> SecurID reads any expressions after OR and then evaluates the next condition statement in the rule set.
Location is not trusted <action> SecurID performs the action defined for the condition.
Location is not trusted AND/OR <attribute><operator> <value> <action> SecurID reads any expressions after AND or OR and then evaluates the next condition statement in the rule set.

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 or Delete a Trusted Location.

  2. Add conditions to your access policies to include Trusted Location attributes. See Add, Clone, or Delete an Access Policy.

Usage Guidelines for the Country and Trusted Location Attributes

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

Example Country Attribute Conditional Expressions

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 SecurID cannot determine the country through HTML geolocation, users in the specified network must authenticate at high assurance level. All other users are denied access.

Example Trusted Location Conditional Expressions

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 SecurID cannot determine the country through HTML geolocation, Trusted Location is evaluated as false (untrusted) and the user is denied access.

How Location is Collected for the Country and Trusted Location Attributes

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

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