WebSphere Commerce access control policies

This section provides a very brief introduction to the main components of the WebSphere Commerce access control framework. It is provided so that some of the access control related programming tasks are viewed in the correct context.

The WebSphere Commerce access control model is based upon the enforcement of access control policies. Access control policies allow access control rules to be externalized from business logic code, thereby removing the need to hard code access control statements into code. For example, you do not need to include code similar to the following: 

if (user.isAdministrator())
 then {}

Access control policies are enforced by the access control policy manager. In general, when a user attempts to access a protected resource, the access control policy manager first determines what access control policies are applicable for that protected resource, and then, based upon the applicable access control policies, it determines if the user is allowed to access the requested resources.

An access control policy is a 4-tuple policy that is stored in the ACPOLICY table. Each access control policy takes the following form: 

AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]

The elements in the 4-tuple access control policy specify that a user belonging to a specific user group is permitted to perform actions in the specified
action group on resources belonging to the specified resource group, as long as the user satisfies the conditions specified in the relationship or relationship group, with respect to the resource in question. For example, [AllUsers, UpdateDoc, doc, creator] specifies that all users can update a document, if they are the creator of the document.

The user group is a specific type of member group that is defined in the MBRGRP database table. A user group must be associated with member group type of -2. The value of -2 represents an access group and is defined in the MBRGRPTYPE table. The association between the user group and member group type is stored in the MBRGRPUSG table.

The membership of a user into a particular user group may be stated explicitly or implicitly. An explicit specification occurs if the MBRGRPMBR table states that the user belongs to a particular member group. An implicit specification occurs if the user satisfies a condition (for example, all users that fulfill the role of Product Manager) that is stated in the MBRGRPCOND table. There may also be combined conditions (for example, all users that fulfill the role of Product Manager and that have been in the role for at least 6 months) or explicit exclusions.

Most conditions to include a user in a user group are based upon the user fulfilling a particular role. For example, there could be an access control policy that allows all users that fulfill the Product Manager role to perform catalog management operations. In this case, any user that has been assigned the Product Manager role in the MBRROLE table is then implicitly included in the user group.

The ActionGroup element comes from the ACACTGRP table. An action group refers to an explicitly specified group of actions. The listing of actions is stored in the ACACTION table and the relationship of each action to its
action group (or groups) is stored in the ACACTACTGP table. An example of an action group is the "OrderWriteCommands" action group. This action group includes the following actions that are used to update orders:

A resource group is a mechanism to group together particular types of resources. Membership of a resource in a resource group can be specified in one of two ways:

In most cases, it is sufficient to use the ACRESGPRES table for associating resources to resource groups. Using this method, resources are defined in the ACRESCGRY table using their Java class name. Then, these resources are associated with the appropriate resource groups (ACRESGRP table) using the ACRESGPRES association table. In cases where the Java class name alone is not sufficient to define the members of a resource group (for example, if further restrict the objects of this class based on an attribute of the resource), the resource group can be defined entirely using the conditions column of the ACRESGRP table. Note that in order to perform this grouping of resources based on an attribute, the resource must also implement the Groupable interface.

The following diagram shows an example resource grouping specification. In this example resource group 10023 includes all the resources that are associated with it in the ACRESGPRES table. Resource group 10070 is defined using the conditions field column in the ACRESGRP table. This resource group includes instances of the Order remote interface, that also have status = "Z" (specifying a shared requisition list).

The MEMBER_ID column of the ACACTGRP, ACRESGRP, and ACRELGRP tables should have a value of -2001 (Root Organization).

The access control policy can optionally include either a Relationship or RelationshipGroup element as its fourth element.

If your access control policy uses a Relationship element, this comes from the ACRELATION table. If, on the other hand, it includes a RelationshipGroup element, that comes from the ACRELGRP table. Note that neither need be included, but if you include one, you cannot include the other. A RelationshipGroup specification from the ACRELGRP table takes precedence over the Relationship information from the ACRELATION table.

The ACRELATION table specifies the types of relationships that exist between users and resources. Some examples of types of relationships include creator, submitter, and owner. An example of the use of the relationship element is to use it to ensure that the creator of an order can always update the order.

The ACRELGRP table specifies the types of relationship groups that can be associated with particular resources. A relationship group is a grouping of one or more relationship chains. A relationship chain is a series of one more relationships. An example of a relationship group is to specify that a user must be the creator of the resource and also belong to the buying organizational entity that is referenced in the resource.

The relationship group (or relationship) specification is an optional part of the access control policy. It is commonly used if you have created your own commands and these commands are not restricted to certain roles. In these cases, you might want to enforce a relationship between the user and the resource. Typically, if commands are to be restricted to certain roles, it is accomplished through the UserGroup element of the access control policy rather than by using the Relationship element.

Another important concept related to access control policies is the concept of access control policy groups. WebSphere Commerce V5.5 supports various business models, and each business model has its own set of access control policies. In order to group the sets of policies within the models, policy groups are used. Policies are explicitly assigned to appropriate policy groups and then organizations can subscribe to one or more of these policy groups. In previous versions of WebSphere Commerce, a policy applied to all resources owned by the descendants of that policy's owner organization.

In WebSphere Commerce, if an organization subscribes to one or more policy groups, only the policies in those policy groups will apply to the resources of that organization. If a resource is owned by an organization that does not subscribe to any policy groups, the access control policy manager will search up the organization hierarchy until it encounters the closest ancestor organization that subscribes to at least one policy group; once found, it will apply the policies belonging to those policy groups.

Consider the following diagram:

For any resources owned by the Seller Organization, the policies in the Seller Organization policy group and those in the Root Organization policy group apply. These policies are applicable because the Seller Organization explicitly subscribes to those two policy groups (the dotted arrows show the subscription). In total, three policies apply for this organization. This example is one where the organization that owned the resource explicitly subscribes to policy groups. The diagram also shows an example where the organization does not explicitly subscribe to any policy groups, so the access control framework must look farther up in the hierarchy. For resources that are owned by Default Organization, one must go up the hierarchy to the Root Organization. The Root Organization only subscribes to one policy group, so those are the only policies (policies 1 and 2) that apply to the resources of the Default Organization.

Related concepts

Understanding access control
Access control interactions
Protectable interface
Groupable interface

Related tasks

Implementing access control
Create an access control policy