Secure > Authorization > Customize default access control policies
Relationships between role-based and resource-level policies
This topic describes how policies are related to each other and why understand their relationships before you can modify an existing policy, or create a new one. In many cases, change several policies to properly implement a change.
Understand the relationship between role-based and resource-level policies
In WebSphere Commerce, each action that can be taken by a user is assigned to one or more roles using role-based policies...
- Each default role has a corresponding access group. For instance, the access group for the role Seller is Sellers.
- Each role-based access group generally has two associated role-based policies:
- A policy that defines the controller commands the role is authorized to execute.
- A policy that defines the view actions the role is authorized to execute. View actions map to views in the Struts configuration files. For instance,OperationalReportsHomeRHSView displays a Web page with the list of operational reports that the Seller has access to.
Some controller commands have only a role-based policy, but no resource-level policy. This occurs if the command is not operating on any protectable resources. For example, the command SetCurrencyPreferenceCmd does not need a resource-level policy since it can only change the currency preference for the user running the command. If it was able to change the currency preference of another user, then the user object would have to be protected, and a resource-level policy would be needed.
Resource-level policies for controller commands are directly related to certain role-based policies for controller commands. In the resource-level policy, the controller command is part of the action group, but in the role-based policy, the controller command is part of the resource group. The following figure illustrates this relationship. The resource-level policy includes Roles A and B in its access group, which brings the role-based policies for Roles A and B into play. While the resource-level policy grants authorization for users with roles A or B to take certain actions on a specific set of resources, the associated role-based policies provide authorization for users with roles A and B to take those actions in general.
Relationship between a resource-level policy and its associated role-based policies
This diagram shows a sample resource-level policy that authorizes users in the People access group to read or study certain resources - namely books, magazines, and newspapers. This policy is correctly formulated because the role-based policies for the roles, child and adult also authorize them to read or study books, magazines, and newspapers.
A resource-level policy and the role-based policies that affect it
Notice that in role-based policies for controller commands:
- The action group contains only a single action: Execute.
- The resource group contains the controller command that can be executed.
Similarly, in role-based policies for views:
- The action group contains the views that can be executed.
- The resource group contains a single resource: com.ibm.commerce.command.ViewCommand.
On the other hand, in resource-level policies:
- The action group contains the set of actions that can be performed on the resources in the resource group.
- The resource group contains a list of the actual business resources that can be acted upon.
A resource-level policy can only authorize users in a particular role to take actions already authorized by the corresponding role-based policy. For instance, in the preceding example, the role child is authorized to take the following actions:
- Study
- Read
- Play
Suppose that the resource-level policy is now changed to include a new action called work. Users with the role adult will be able to perform the action work. However, users with the role child will not. The reason for this is apparent when you check the role-based policies for the two roles. The policy for adult lists the action work in its resource group. The policy for child does not. Even though both child and adult are properly authorized by the resource-level policy, the role-based policy for child does not authorize the action work.
Because of the way resource-level policies are tied to role-based policies, the best way to track down all the policies affected by a particular change is to work backwards from the resource-level policy. The first step is to examine the access group of the resource-level policy and determine if it contains any roles. You can view the complete list of default roles by selecting Access Management > Roles from the Organization Administration Console.
If the resource-level policy's access group includes roles, review their role-based policies to see whether they need to be changed. If you are adding an action to the action group of a resource-level policy, make sure that the relevant role-based policies also authorize the new action. If you are deleting an action from a resource-level policy, and no other resource-level policies reference this action, it is best to remove the corresponding resource from the associated role-based policies.
Understand the policy model
An authorizing policy must be present for a user to perform an action. However, WebSphere Commerce permits users to take an action if any policy provides the needed authorization. Therefore, if you define a new, more restrictive policy than the default, delete or modify the broader default policy to prevent it from overriding the new policy.
For instance, suppose default policy A authorizes all registered users to submit auction bids. You want to change this policy so that auction bidding is limited to users with the buyer role. If you merely define a new policy that authorizes buyers to create auction bids, then the new policy will have no effect. Default policy A will still permit all registered users to bid.
To make the new policy take effect, delete the broader, default policy.
The following table summarizes the additional changes make when you create, delete, or change a resource-level policy.
Table 1. Additional changes needed when you change a resource-level policy that uses roles. Change to a resource-level policy Required change if the resource-level's access group uses roles Add an action to the policy's action group. Verify the applicable role-based policies include the action in their resource groups. Remove an action from the policy's action group. No additional change required. For consistency, it is better to remove this action from the corresponding resource groups in the related role-based policies. This should only be done if no other action groups are referring to this action. If other action groups are referring to this action, likely there are role-based policies that still need to have this action in their resource group. Use a different action group. Verify the applicable role-based policies include in their resource groups the new action group's actions. Add a role to the policy's access group. Verify the role-based policy corresponding to the new role, refers to a resource group that includes the actions specified in the resource-level policy. Remove a role from the policy's access group. No additional change required. For consistency, it is better to modify the corresponding role-based policy so that it no longer references these actions in its resource group. Use a different access group. Verify the applicable role-based policies include in their resource groups the actions in the resource-level policy's action group. Create a new policy. Check whether there is an existing policy that authorizes the same actions. Delete if necessary. Delete the policy. To prevent any users from taking that policy's actions, delete any other policies that authorize the same actions.
Related concepts
Role-based and resource-level policies
Related tasks
Load access control policy data
Related reference
Examples: Customizing access control policies using the Organization Administration Console