Access policies determine which users can access applications or authentication clients and whether those users must perform additional authentication, after primary authentication, in order to use the applications. You assign an access policy when you add an application or authentication client to RSA SecurID Access using the Cloud Administration Console.
Note: If you have an SSO Agent deployment and use deep links, see the Help topic "Deep Linking" at https://community.rsa.com/docs/DOC-54147 to understand how the policy is evaluated with application access attempts.
High-Level Processing Summary for Access Policies
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 that user population is allowed or denied access.
- RSA SecurID Access uses the Additional Authentication field to determine if additional authentication is required. Contextual conditions may be used to filter designated groups of users or require them to use different authentication methods.
- If multiple rule sets are used, RSA SecurID Access continues to process each one in sequence.
The following sections describe this process in detail.
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).
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. 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:
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 (SSO Agent, relying parties, and RADIUS clients):
- Identity Sources for the Cloud Authentication Service
- Active Directory Attributes Synchronized for Authentication
- LDAPv3 Directory Server Attributes Synchronized for Authentication
User Attributes to Control Application Visibility in SSO Agent Deployments
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.
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. RSA SecurID Access ignores the next rule set that denies access based on user attributes.
Access Field: Allow or Deny
After selecting the user population, RSA SecurID Access uses the Access field setting to determine access as described in the following table.
|Access Field Setting||Result|
RSA SecurID Access evaluates the request to determine if additional authentication is required to use the application, and if so, under what conditions. These requirements are in the policy's Authentication Details section.
In SSO Agent deployments, users can see the application in the portal if Access is set to Allowed.
Users cannot use the application.
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 application or authentication client access.
You can allow or deny application or relying party access to users depending on whether they match conditions that you define. Authentication conditions are restrictions based on the context of the user's request. 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 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 the Help topic "Deep Linking" at https://community.rsa.com/docs/DOC-54147 for information on how these conditions are evaluated.
Order of Evaluation for Authentication Conditions
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 open the application or relying party 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
Your RSA SecurID Access product license 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 applications or relying parties. The following table shows which attributes are available with each license.
|Access Policy Attributes||Base Edition||Enterprise Edition||Premium Edition|
|Identity source attributes||x||x|
|Basic Policy Engine attribute: IP address||x||x|
Advanced Policy Engine attributes:
|Risk-based Identity Confidence||x|
Identity source attributes are used to select the target user population for an access policy. Policy Engine attributes are used in access policy conditions.
Allowing All Authenticated Users for SSO Agent Deployments
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, in the Authentication Details section, 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.
Table of Contents > Access Policies > Access Policies