Evaluate access control policies
Overview
This section presents a scenario for evaluating groupable standard and groupable template access control policies.
Organizational hierarchy
The diagram contains the following organizations...
- Root Organization
- Seller Organization
- Default Organization
- Division A Organization Unit
Solid lines indicate ownership. Dotted lines indicat subscriptions.
The Root organization is the parent of Seller organization, and Default organization.
Seller Organization is the parent of Division A Organization Unit.
Users
In the diagram, Don and Emily are registered to the Seller Organization. Abe, Billy and Carol are registered to Division A Organization Unit. Guest user 1 has not registered, but for access control purposes, implicitly belongs to the Default Organization.
Roles
Don has the approver role for the Seller Organization. Abe has the approver role for the Division A Organization Unit.
Access Groups
The following access groups are used in this scenario:
Registered users Implicitly includes all users registered to at least one organization in the site. Approvers for Seller Implicitly includes all users with role of approver for the Seller organization. Approvers for Division A Implicitly includes all users with role of approver for the Division A Organization Unit.
Documents
The document object is a protected resource. The owner of a document is defined to be the organization where it was created.
Access control requirements related to updating documents
- Registered users can update a document of which they are the creator.
- Approvers for Division A can update documents owned by Division A, but not documents owned by Seller. Approvers for Seller organization can update documents owned by both Division A, and Seller organization.
Access control polices related to updating documents
The following is the policy format and the access control policies that relate to updating documents:
Policy Format: [Access Group, Action Group, Resource Group, Relationship]
- Policy 1
[Registered Users, Execute Command Action Group, Update Document Resource Group, - ]
This is a groupable standard role-based policy that is part of the Root Organization policy group to which Root Organization, Seller Organization and Division A Organizational Unit are subscribing. In this policy, registered users can execute Update Document commands.
- Policy 2
[Registered Users, Update Document Action Group, document, creator ]
This is a groupable standard resource-level policy that is part of the Root Organization policy group to which Root Organization, Seller Organization and Division A Organizational Unit are subscribing. In this policy, registered users can update a document if they are the creator of that document.
- Policy 3
[Approvers for Seller, Update Document Action Group, document, - ]
This is a groupable standard resource-level policy that is part of the Seller Organization policy group to which Seller Organization and Division A Organizational Unit are subscribing. In this policy, approvers for Seller can update documents that are owned by Seller.
- Policy 4
[Approvers for Division A, Update Document Action Group, document, - ]
This is a groupable standard resource-level policy that is part of Division A Organization Unit policy group to which Division A is subscribing. In this policy, Approvers for Division A can update documents that are owned by Division A.
Scenarios
Scenario 1 : Billy attempts to update his own document
- Command - level check
- There is no store ID specified, so the owner of the command is set to Root Organization. So, only policies belonging to the policy groups subscribed to by Root Organization will be used to evaluate whether the user has command-level access: policies 1 and 2 are part of the policy group that to which Root Organization is subscribing.
- Policy 1 grants access, since Billy is a member of the Registered Users access group and he is performing the Execute action on the Update Document command resource.
- Resource - level check
- The Update Document command specifies that the document resource is to be protected. Billy's document is owned by Division A. Since Division A subscribes to policy groups, all policies belonging to those policy groups will apply: policies 1, 2, 3 and 4.
- Policy 2 grants access since Billy is a member of the Registered Users access group, he is performing the Update Document command action on the document resource, and he fulfills the creator relationship with the document.
Since Billy passed both the command-level and resource-level access control checks, he can update his own document.
Scenario 2: Don attempts to update Carol's document
The following is the access control evaluation for this scenario:
- Command - level check
- There is no store ID specified, so the owner of the command is set to Root organization. So, only policies belonging to the policy groups subscribed to by Root Organization will be used to evaluate whether the user has command-level access: policies 1 and 2 are owned by Root organization.
- Policy 1 grants access, since Don is a member of the Registered Users access group and he is performing the Execute action on the Update Document command resource.
- Resource - level check
- The Update Document command specifies that the document resource is to be protected. Carol's document is owned by Division A. Since Division A subscribes to policy groups, all policies belonging to those policy groups will apply: policies 1, 2, 3 and 4.
- Policy 3 grants access since Don is a member of the Approvers for Seller access group, and he is performing the Update Document command action on the document resource.
Since Don passed both the command-level and resource-level access control checks, he can update Carol's document.
Scenario 3: Abe attempts to update Emily's document
- Command - level check
- There is no store ID specified, so the owner of the command is set to Root organization. So, only policies belonging to the policy groups subscribed to by Root Organization will be used to evaluate whether the user has command-level access: policies 1 and 2 are owned by Root organization.
- Policy 1 grants access, since Abe is a member of the Registered Users access group and he is performing the Execute action on the Update Document command resource.
- Resource - level check
- The Update Document command specifies that the document resource is to be protected. Emily's document is owned by Seller organization. Since Seller Organization subscribes to policy groups, all policies belonging to those policy groups will apply: policies 1, 2 and 3.
- Policy 3 does NOT grant access since Abe is NOT a member of the Approvers for the Seller access group.
Although Abe passed the command-level check, since he failed the resource-level access control check, he cannot update Emily's document.
Scenario 4: Guest user 1 attempts to update his own document
The following is the access control evaluation for this scenario:
- Command - level check
- There is no store ID specified, so the owner of the command is set to Root Organization. So, only policies belonging to the policy groups subscribed to by Root Organization will be used to evaluate whether the user has command-level access: policies 1 and 2 are owned by Root Organization.
- Policy 1 does NOT grant access, since Guest user 1 is NOT a member of the Registered Users access group.
- Resource - level check
- Resource-level checking is not done since the command-level check failed
Since Guest user 1 failed the command-level check, he cannot update his own document.
Evaluate groupable template policies
Access control policies related to updating documents
In this configuration, access control policies 1 and 2 still apply, however, groupable standard policies 3 and 4 are now replaced by groupable template policy 5. For more information about policies 1 and 2 see, Evaluate groupable standard policies.
Policy 5
[Approvers for Organization, Update Document Action Group, document, - ]
This policy is a groupable template resource-level policy. It is part of the Root Organization policy group to which Root Organization is subscribing. Groupable template policies dynamically apply to the organization that owns the resource during run time. These policies typically use parameterized access groups. In this case, the following parameterized access group is used:
- Approvers for Organization: This group implicitly includes all users that have the role of approver for the organization that owns the document resource or for its ancestor organizations.
Scenarios
The following scenarios are based on the configuration shown in the previous diagram which has only one policy group. Root Organization policy group includes policies 1, 2, and 5.
Scenario 1: Don attempts to update Carol's document
- Command - level check
- There is no store ID specified, so the owner of the command is set to Root organization. So, only policies belonging to policy groups subscribed by Root Organization will be used to evaluate whether the user has command-level access: policies 1, 2, and 5.
- Policy 1 grants access, since Don is a member of the Registered Users access group and he is performing the Execute action on the Update Document command resource.
- Resource - level check
- The Update Document command specifies that the document resource is to be protected. Carol's document is owned by Division A. Division A does not subscribe to any policy groups, so the access control framework will begin searching up the organization hierarchy until it encounters an organization that subscribes to at least one policy group. Division A's immediate parent organization, Seller Organization, also does not subscribe to policy groups. Continuing up the organization hierarchy, Root Organization is reached. This organization subscribes to a policy group; thus its policies can be applied: policies 1, 2, and 5.
- Groupable template policy 5 is applied to the organization that owns the resource: Division A. The parameterized access group, Approvers for Organization, dynamically scopes to the current resource context such that it will check if the user satisfies the access group condition for the organization that owns the resource or its ancestors. In this case, Don is an approver for Seller Organization (an ancestor of Division A), so he satisfies the conditions of the access group. Since he is performing the Update Document command action on the document resource, the other elements of policy 5 are also satisfied, so the resource-level policy check passes.
Since Don passed both the command-level and resource-level access control checks, he can update Carol's document.
Scenario 2: Abe attempts to update Emily's document
- Command - level check
- There is no store ID specified, so the owner of the command is set to Root organization. So, only policies belonging to policy groups subscribed by Root Organization will be used to evaluate whether the user has command-level access: policies 1, 2, and 5.
- Policy 1 grants access, since Abe is a member of the Registered Users access group and he is performing the Execute action on the Update Document command resource.
- Resource - level check
- TheUpdate Document command specifies that the document resource is to be protected. Emily's document is owned by Seller Organization. Seller Organization does not subscribe to any policy groups, so the access control framework will begin searching up the organization hierarchy until it encounters an organization that subscribes to at least one policy group. Continuing up the organization hierarchy, Root Organization is reached. This organization subscribes to a policy group; thus its policies can be applied: policies 1, 2 and 5.
- Groupable template policy 5 is applied to the organization that owns the resource: Seller Organization. The parameterized access group, Approvers for Organization, dynamically scopes to the current resource context such that it will check if the user satisfies the access group condition for the organization that owns the resource or its ancestors. In this case, Abe is an approver for Division A Organization Unit (a descendant of Seller Organization), so he does not satisfy the conditions of the access group.
Although Abe passed the command-level check, since he failed the resource-level access control check, he cannot update Emily's document.
Related
Authorization
Customize default access control policies
Define access control policy elements using XML
Implement access control
Examples: Customizing access control policies using the Organization Administration Console