Access PoliciesAccess 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 RSA SecurID Access using the Cloud Administration Console.
For information on planning access policies, see Planning Resource Protection with Multifactor Authentication (MFA). To add an access policy, see Add, Clone, or Delete an Access Policy.
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 ProcessingAccess Policy Processing
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 RSA SecurID Authenticate Device Registration policy does not support additional authentication at this time. For more information, see Device Registration Using Password Policy.
If multiple rule sets are used, RSA SecurID Access continues to process each one in sequence.
The following sections describe this process in detail.
Using Identity Sources to Identify the Target PopulationUsing 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 SetsRule 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 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 PoliciesMaking 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
- Directory Server Attributes Synchronized for Authentication
User Attributes to Control Application Visibility in SSO Agent DeploymentsUser 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.
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 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 FieldAccess Field
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|
Cloud Authentication Service evaluates the request to determine if additional authentication is required.
In 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.|
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 ConditionsAuthentication 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 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 ConditionsOrder 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 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 AttributesProduct 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 edition.
|Access Policy Attributes||Base Edition||Enterprise Edition||Premium Edition|
|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:
Premium Edition attributes include all attributes listed above and the following conditional attributes:
Allowing All Authenticated Users for SSO Agent Deployments 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, 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.