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 you 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:
- 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, you need to 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.
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, you 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, you must delete the broader, default policy.
The following table summarizes the additional changes you need to make when you create, delete, or change a resource-level policy.
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. |