Relationships between role-based and resource-level policies

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.