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 RSA SecurID Access using the Cloud Administration Console.
RSA SecurID Access evaluates an access policy by performing the following high-level steps.
RSA SecurID Access identifies the target user population for the policy using the Identity Source field on the Identity Sources page of the policy.
RSA SecurID Access 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.
RSA SecurID Access uses the Access field to determine if user access is allowed or denied or determined based on contextual conditions.
RSA SecurID Access 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 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).
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. RSA SecurID Access 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:
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 (SSO Agent, relying parties, and RADIUS clients):
In deployments that use the 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.
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
Users must match attributes for the Manufacturing group.
Apply to All Users, includes all users who authenticate
to the application portal.
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. RSA SecurID Access ignores the next rule set that denies access based on user attributes.
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 you use managed bookmarks to push application links to your users, see Deep Linking for information on how these conditions are evaluated.
RSA SecurID Access 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.
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 edition.
Access Policy Attributes
Identity source attributes (used in rule sets to select target population for policy)
IP address (conditional attribute)
Additional conditional attributes:
Premium Edition attributes include all attributes listed above and the following conditional attributes:
If your deployment uses the 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 RSA SecurID Access. 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.