The 2016 RSA Via Access Spring Release is changing the way context related attributes are used in application access policies. Rather than defining who has access based on user store attributes and session attributes (IP, User Agent String, Authentication Source, Authentication Type), administrators will define access based on user store attributes and authentication decisions will be based on session and context attributes.
In other words, session attributes will be moved into the authentication conditions section of a policy. All existing policies will be migrated to the new structure and existing session attributes will be moved into authentication conditions. To ensure that migration will complete as smoothly as possible, we are providing a brief list of best practices.
If you follow the best practices, migration is likely to complete without issues and without changing the policy rule logic. If you do not follow the best practices, you might need to revisit the policy logic after migration. All the information about the previous policy structure will be saved and will be available to RSA customer support. The policy description will clearly indicate if a policy that was migrated required a logic change.
Note: All existing policies created before April 27, 2016 should be migrated successfully even if they do not follow best practices. For new policies you create, please follow these best practices. This is a one-time migration. After the migration is complete there are no longer limitation on creation of new policies or modifications to old ones.
Best Practices
Note: All best practices relate to policies using session attributes only. If a policy is not using any session attributes, there are no limitations on those policies.
- 1. Avoid using more than one rule set in a policy when Match=All and the user criteria contains both access attributes (based on user store) and session attributes.
Example: The following two rule sets both contain user store attributes and session attributes
- Ruleset 1: Match all: ad group=sales , ip value=x Action: Allow
- Ruleset 2: Match all sAMAccountName= “James”, authenticationSource=“z” Action: Authenticate
Will be migrated to:
- Ruleset 1: ad group=sales
condition ip value=x, Action: Allow
default: Deny
- Ruleset 2: sAMAccountName= “James:
condition: authenticationSource=“z” Action: Authenticate
Default: Deny
Explanation: After the rule sets are migrated, If the user attributes match for Ruleset 1, Ruleset 1 is going to be selected for evaluation. Even if the conditions are not satisfied, Ruleset 2 is not going to be evaluated although it would have been evaluated before migration
2) Do not use more than two rule sets in a policy if any session attributes are used in the user criteria. The problem is that attributes might lose priority.
If a policy containing session attributes has more than two rule sets, the migration will do best effort and flag this as requiring attention.
3) Do not create new policies with conditions until after the migration.
Note: This relates to policies using session attributes as well as conditions. If a policy is not using session attributes, there are no limitations on using conditions.
If policies created after April 27, 2016 contain session attributes and conditions, the migration will do best effort and flag this as requiring attention.
4) Do not create policies that just deny all access.
Example:
- Ruleset1: Match all: ad group=sales , ip value=x Action: Deny
- Ruleset2: Match all sAMAccountName= “James”, authenticationSource=“z” Action: Deny
Note: This policy does not make sense as all access is deny. The identical semantic cannot be created using conditions.
FAQ:
Q: What happens if I see that my policy has changes by migration and a flag (MIG-1, MIG-2,..MING-4) appears in the policy description section?
A: Take a look at the release notes to find more information about the next steps and the migration codes. You can review the policy to ensure the logic is sound or change it to fit what you expect. If you cannot create the required logic, please contact RSA Customer Support for assistance.
