Relationships between role-based and resource-level policies

This topic describes how policies are related to each other and why you need to understand their relationships before we can modify an existing policy, or create a new one. In many cases, you need to change several policies to properly implement a change.


Understanding 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 as follows:

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:

Similarly, in role-based policies for views:

On the other hand, in resource-level policies:

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:

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. We 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 we are adding an action to the action group of a resource-level policy, you need to make sure that the relevant role-based policies also authorize the new action. If we 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.


Understanding 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, we must delete or modify the broader default policy to prevent it from overriding your 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 your new policy will have no effect. Default policy A will still permit all registered users to bid. To make your new policy take effect, we must delete the broader, default policy.

The following table summarizes the additional changes you need to make when creating, 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. Ensure that 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. Ensure that 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. Ensure that 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. Ensure that 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
Authorization
Role-based and resource-level policies


Related tasks
Loading access control policy data


Related reference
Examples: Customize access control policies using the Organization Administration Console