Access Policies

Access policies determine which users can complete authenticator registration and access applications or authentication clients. Policies also determine whether those users must perform additional authentication, after primary authentication, in order to use the resources. You assign an access policy when you add an application or authentication client to SecurID using the Cloud Administration Console.

For more information, see:

Note: If you have an SSO Agent deployment and use deep links, see Deep Linking to understand how the policy is evaluated with application access attempts.

Access Policy Processing

SecurID evaluates an access policy by performing the following high-level steps.

  1. SecurID identifies the target user population for the policy using the Identity Source field on the Identity Sources page of the policy.

  2. SecurID goes to the first rule set and uses the Target Population field to determine if the rule set applies to all users or only to users who match LDAP user attribute criteria.

  3. SecurID uses the Access field to determine if user access is allowed or denied or determined based on contextual conditions.

  4. SecurID uses the Additional Authentication field to determine if additional (step-up) authentication is required. Contextual conditions may be used to filter designated groups of users or require them to use different authentication methods.

    The SecurID Authenticate Device Registration policy does not support additional authentication at this time. For more information, see Device Registration Using Password Policy.

  5. If multiple rule sets are used, SecurID continues to process each one in sequence.

The following sections describe this process in detail.

Using Identity Sources to Identify the Target Population

The policy targets users who are in an identity source that you select. If you do not specify any identity source, then the target population includes all users who access the application or authentication client by any means, for example, by signing into the portal or through Integrated Windows Authentication (IWA).

Rule Sets

An access policy contains one or more rule sets. A rule set contains:

  • User attributes that select the user population for this rule set.
  • Authentication requirements that apply to the user population that is allowed access. These requirements include the assurance levels, which define the users' authentication options.

A policy can have multiple rule sets that serve different purposes. You can add a rule set for each subpopulation within your company that has its own authentication requirements.

Identity Source User Attributes

Identity source attributes are used to further filter the user population. Users must match the specified user attributes, such as department or job level. You can allow or deny access based on these attributes.

You specify user attributes in expressions containing a user attribute, operation, and value. SecurID attempts to match the user's request with at least one user attribute expression to select the target user population. For example, the following user attribute expression selects all permanent employees:

User Attribute Operation Value
employeeType MATCHES Permanent

Making Identity Source Attributes Available to Access Policies

Follow these best practices to ensure that identity source attributes are available to access policies:

  • When you add the identity source, on the User Attributes page, select which attributes (in the Policies column) to make available to access policies.
  • Also when you add the identity source, make sure identity source synchronization is enabled by selecting Synchronize user attributes for additional authentication. Without synchronization, only policies that allow all authenticated users will display applications or authentication clients that the user can access based on authentication requirements.
  • When you add the access policy, select at least one identity source for the policy.

See the following topics for guidance on synchronizing identity source attributes in each type of deployment (IDR SSO Agent, relying parties, and RADIUS clients):

User Attributes to Control Application Visibility in IDR SSO Agent Deployments

In deployments that use the IDR SSO Agent, if you do not specify user attributes from a selected identity source, then all users who access the portal through IWA or an external SAML IdP can view all of the applications in the portal. You can require additional authentication to control which users in this population can use these applications. Make sure you specify attributes in the access policy to control who sees the applications in the portal.

If you do not want users to use any application, you can use access policies to filter the users. Access policies determine which applications users can access. Users can see only those applications they are authorized to use. Users without access to any application can sign in to the portal but cannot view any application.

Evaluation Order for Rule Sets and User Attributes

Rule sets and user attributes are evaluated in the order in which they appear in the access policy. You can drag and drop rule sets to change the order and allow or deny access to specific groups of users. For user attributes, you must delete and re-add to change the order.

A user request is denied access as soon as it matches a user attribute or condition that denies access. After a denial, any subsequent matches are ignored.

Note: Use caution when adding multiple rule sets with overlapping user populations or multiple authentication conditions. The rule sets, user attributes, and conditions must be ordered correctly to produce the intended results.

Any users who are not explicitly allowed or denied access in a rule set are denied access.

The following example shows two rule sets in a policy.

Order in Policy Rule Set Access Field
1 Users must match attributes for the Manufacturing group. Denied
2 Apply to All Users, includes all users who authenticate to the application portal. Allowed

Rule set 1 denies access based on user attributes, while rule set 2 allows access to all remaining users who were not denied access by rule set 1. You can reverse the order for different results. When reversed, the Apply to All Users rule set is evaluated first and allows access to all users. SecurID ignores the next rule set that denies access based on user attributes.

Access Field

After selecting the user population, SecurID uses the Access field setting to determine access as described in the following table.

Access Field Setting Result
Allowed

Cloud Authentication Service evaluates the request to determine if additional authentication is required.

In IDR SSO Agent deployments, users can see the application in the portal if Access is set to Allowed.

Conditional Cloud Authentication Service evaluates the request based on conditions to determine if the user is allowed or denied or additional authentication is required.
Denied

User is denied.

If the user request does not match any user attribute expressions in the rule set, one of the following occurs:

  • If the policy contains one rule set, the user is denied access.
  • If the policy contains multiple rule sets, the user request is passed to the next rule set for evaluation.

Note: All user requests that do not match any user attributes in any rule set in a policy are denied access.

Authentication Conditions

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.

If your deployment uses the IDR SSO Agent, you can specify additional authentication for the application portal by configuring the Portal Multi-Factor Authentication Policy. For more information, see Portal Multifactor Authentication Policy.

If you use managed bookmarks to push application links to your users, see Deep Linking for information on how these conditions are evaluated.

Order of Evaluation for Authentication Conditions

SecurID evaluates conditions in the order in which they are listed in the rule set. The first condition that is satisfied determines whether the user is allowed access without further authentication, is denied access, or must use additional authentication. If denied access, the user cannot access the resource and an appropriate message appears. You can drag and drop to reorder conditions.

The final condition in the list is a default and is used only if no other condition is satisfied. By default, this condition has no attributes and denies access. You can modify the Access field for this rule.

Product Licensing for Access Policy Attributes

The Cloud Authentication Service allows you to use specific attributes in access policy conditional expressions. These expressions are used to determine authentication requirements and who is allowed or denied access to resources. The following table shows which attributes are available with each license.

Access Policy Attributes

Cloud

Cloud Plus

Cloud Premier
Identity source attributes (used in rule sets to select target population for policy) x x x
IP address (conditional attribute) x x x

Additional conditional attributes:

  • Authentication Type

  • Authentication Source

  • Country

  • Known Browser

  • Trusted Location

  • Trusted Network

  • User Agent

 x x

Cloud Premier attributes include all attributes listed above and the following conditional attributes:

  • High-Risk User List

  • Identity Confidence

 x

Allowing All Authenticated Users for IDR SSO Agent Deployments

If your deployment uses the IDR SSO Agent, you can allow all users who complete primary authentication to access an application without additional authentication. You can accomplish this in either of two ways:

  • Select the All Authenticated Users policy when you add the application to SecurID. You cannot modify this policy.

  • Configure a rule set as follows: on the Rule Sets page, in the Apply to field, select All Users. This allows all authenticated users who access the portal to view the application icon in the portal. If you want all users to be able to use the application without additional authentication, select Not Required.

    Note: If you select at least one identity source, All Users includes only users in selected identity sources. If you do not select any identity sources, access is granted to all users in identity sources configured for the Cloud Authentication Service.

Related Tasks

Add, Clone, or Delete an Access Policy

Related References

Access Policy Examples

Manage Access Policies