Role-based and resource-level policies

Role-based policies are also known as command-level policies because they authorize users with a particular role to execute a set of commands. Resource-level policies authorize a group of users to execute a set of commands on a particular set of resources. For instance, a role-based policy might authorize children to eat. While a resource-level policy might authorize children eat rice.

We can usually determine whether a policy is a role-based policy or a resource-level policy by looking at its name.

Role-based policies

Policies that define the controller commands that a role can execute follow the naming convention:

<AccessGroupforRoleXYZ> Execute <XYZCmdResourceGroup>

For instance: ProductManagersExecuteProductManagersCmdResourceGroup.

In role-based policies for controller commands, the action group contains a single entry called Execute and the resource group contains a list of WebSphere Commerce commands that users with that role can execute.

Policies that define the views that a role can execute follow the naming convention:

<AccessGroupforRoleXYZ> Execute <XYZViews>

For instance: SalesManagersExecuteSalesManagersViews.

The resource group contains a single resource called com.ibm.commerce.command.ViewCommand.

Resource-level policies

Policies that define who can take actions on data resources (business objects that can be created or manipulated) follow the naming convention:

<AccessGroupXYZ> Execute <XYZCommands> On <XYZResource>

For instance: AllUsersExecuteOrderProcessOnOrderResource.

In resource-level policies, the action group contains WebSphere Commerce commands and the resource group identifies the specific business resources that can be acted upon.

One exception is policies that authorize the creation of an entity such as an order, a bid, or an RFQ. These policies do not act on the entity itself because it has not yet been created. Instead, they act on the containing entity. For instance, an auction is created in the context of a store, a user is created in the context of an organization. Most resources are created in the context of a store. Consequently, these policies have names such as:

<AccessGroupXYZs> Execute <XYZCommands> On <StoreEntityResource>

For instance:

AuctionAdministratorsForOrgExecuteAuctionCreateCommandsOnStoreEntityResource

Policies that define who can view DataBean resources (Data beans contain information about data resources such as a bid or an order; usually used in JSPs) follow the naming convention:

<AccessGroupXYZs> Display <XYZDatabeanResourceGroup>

For instance: MembershipViewersForOrgDisplayMembershipDatabeanResourceGroup.

Related concepts
Relationships between role-based and resource-level policies
Authorization

Related tasks
Defining access control policy elements using XML

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