Access control policy

Elements of an access control policy

An access control policy consists of four elements:

Access group

The group of users to which the policy applies.

Action group

A group of actions performed by the user on resources.

Resource group

The resources controlled by the policy. A resource group might include business objects like contract or order, or a set of related commands. For example, all the commands that users of a particular role can perform.

Relationship

Optional: Each resource class can have a set of relationships associated with it. Each resource can have a set of users that fulfill each relationship. For example, a policy could specify that only the creator of an order can modify it. In this case, the relationship would be creator, and it is between the user and the order resource.

Together, these four parts define a policy in WebSphere Commerce by specifying the users, the actions they can take, the business object or set of commands on which their actions are taken, and optionally, the relationship that the users have to the resource group.

Access control policies grant users access to your site. Unless they are authorized to perform their responsibilities through one or more access control policies, users have no access to site functions.

AccessControlPolicy [AccessGroup,ActionGroup,ResourceGroup,Relationship]

The elements in the access control policy specify that a user belonging to a specific access 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 a particular relationship with respect to the resource. The relationship is only specified when needed. For example, [AllUsers,UpdateDoc,doc,creator] specifies that all users can update a document, if they are the creator of the document.

The following sections describe conceptual information and terminology associated with access control.

Member groups

The Member subsystem in WebSphere Commerce allows you to create member groups, which are groups of users categorized for various business reasons. The groupings can be used for many purposes, for example, access control purposes, approval purposes, as well as for marketing purposes such as promotion qualification, and displaying products. A member group of type Access Group (-2) is for access control purposes, while a member group of type User Group (-1) is for general use. A member group is associated with member group types in the MBRGRPUSG table.

Access groups

A member group of type Access Group (-2) is for grouping users for access control purposes. An access group is one element of an access control policy. The criteria for membership in an access group is usually based on roles, the organization to which the user belongs, or the user's registration status. For example, the access group called Buyer Administrators is a group whose users play the role of Buyer Administrator.

WebSphere Commerce includes a number of default roles, and corresponding to each role is a default access group that implicitly references that role. Roles can be used as attributes to add users to an access group based on the type of activities they perform in the site. For example, by default there is a role called Seller Administrator and a corresponding access group called Seller Administrators. A Site Administrator uses the Administration Console to create, maintain, and delete access groups for a site. A Site Administrator, Buyer Administrator, Seller Administrator, or Channel Manager uses the Organization Administration Console to assign roles to users or to explicitly assign users to access groups.

Implicit access group

An implicit access group is defined by a set of criteria. Anyone who satisfies the criteria is a member of the group. The criteria are usually based on a user's roles, parent organization, or registration status. The implicit conditions that define membership in a member group are in the CONDITIONS column of the MBRGRPCOND table. Using implicit access groups that specify the attributes of users, makes it easy to authorize access to similar users without having to explicitly assign and unassign individual users. It also eliminates the need to update the members of a group when a user's attributes change. Furthermore, since multiple access groups can refer to the same user attribute, assigning an attribute to a user can implicitly include that user in multiple access groups. A simple criterion for an access group is to include everyone that has been assigned a specific role, regardless for which organization the user plays the role. A more complex criterion would be to specify that only users that play one of a possible set of roles for a particular organization would belong to the access group.

Explicit access group

It is possible to explicitly add or remove a user from a member group. Both of these explicit specifications can be done using the MBRGRPMBR table. An explicit access group contains explicitly assigned users who may or may not share common attributes. This also allows you to exclude individuals that satisfy the conditions for inclusion in an implicitly defined group, but that you want excluded anyway.

User groups

A member group of type User Group (-1) is a collection of users defined by the merchant, who share a common interest. User groups are similar to clubs that are offered by large stores for their frequent or preferred customers. Being part of a user group can entitle customers to promotions or other bonuses for purchasing products. For example, if market research shows that senior customers repeatedly purchase travel books and luggage, you can assign these customers to a member group called Seniors' Travel Club. Likewise, you can create a user group to reward frequent customers for their business.

Actions

Generally, an action is an operation that is performed on a resource. In role-based policies for controller commands, the action is Execute and the resource is the command being executed. In role-based policies for Views, the action is the name of the view, and the resource is com.ibm.commerce.commands.ViewCommand. For resource-level access control, actions typically map to WebSphere Commerce commands, and the resource is usually the remote interface of a protected EJB ( Enterprise Java Bean). For example, the controller command com.ibm.commerce.order.commands.OrderCancelCmd operates on the com.ibm.commerce.order.objects.Order resource. Lastly, in data bean policies, the Display action is used to allow the activation of data bean resources.

The Administration Console can be used by a Site Administrator to associate existing actions with action groups, but not for creating new actions. New actions can be created by defining them in an XML file and then loading them to the database. Actions are stored in the ACACTION table.

Action groups

Action groups are groups of related actions. An example of an action group is the AccountManage group that includes the following commands:

• com.ibm.commerce.account.commands.AccountDeleteCmd
• com.ibm.commerce.account.commands.AccountSaveCmd

Only the Site Administrator can create, update, and delete action groups. This can be done from the Administration Console and through XML. Action groups are stored in the ACACTGRP table. Actions are associated with action groups in the ACACTACTGP table.

Resource category

Resource category refers to a class of resources that need to be protected by access control. Resources must implement the Protectable interface information. Resource categories are Java classes such as order, and RFQ. Resources are the instances of these classes. For example, Order1 created by Order Administrator A is one resource; Order2 created by Order Administrator B is another resource. These two resources belong to the resource category: order.

Resource categories are defined in the ACRESCGRY table, and for convenience, are sometimes referred to as resources. A Site Administrator can associate existing resource categories with resource groups, using the Administration Console. New resource categories can be created using XML.

Resources

Resources are any objects in the system that need to be protected. For example, RFQs, users, and orders are some of the resources in WebSphere Commerce which need to be protected. Each resource has an owner. The ownership of the resource is used to determine which access control policies apply to it. Access control policies have an owner, which is an organizational entity. A policy is only applied to resources that are owned by the same organizational entity that subscribes to a policy group, that contains the policy. If the organization that owns the resource does not subscribe to policy groups, then the policies in the policy groups that are subscribed by the closest ancestor organization will be applied.

Controller command resources

For role-based access control for controller commands, the policy is structured such that the Execute action is being performed on the controller command resource. These policies are intended to restrict the execution of controller commands to users with a specified role. The access group for these policies is usually those with a single role, for example, Product Managers (those with the Product Manager role). Then, the resource group would be the set of controller commands that a product manager can execute.

While enforcing role-based access control on a controller command, the owner of the command must be determined. This is done by calling the getOwner() method on the command if it has been implemented. Usually this method is not implemented, so WebSphere Commerce Runtime will evaluate it by doing one of the following:

• Use the organization that owns the store that is currently in the command context.
• If there is no store in the command context, use the Root Organization as the owner.

Data bean resources

Not all data beans require protection. Within the existing WebSphere Commerce application, data beans that require protection already implement the required access control. The question of what to protect comes into play when you create new data beans. Deciding which resources to protect depends upon your application. A data bean should be protected (directly or indirectly), if the information to be displayed is not sufficiently protected by the role-based access control on the view, that corresponds to the JSP (Java Server Page) that contains the data bean.

If a data bean needs to be protected and can exist on its own, it should be directly protected. If the existence of a data bean depends upon the existence of another data bean, then it should delegate to the other data bean for protection. An example of a data bean that would be directly protected is the Order data bean. An example of a data bean that would be indirectly protected is the OrderItem data bean, as it cannot exist without Order data bean.

Data resources

Data resources refer to business objects that can be manipulated such as orders, RFQs, and users. These are usually protected at the enterprise bean level, but it is possible to protect any class, as long as it implements the Protectable interface. Data resources are protected using resource-level access control checks. The common way of doing this by returning data resources in the getResources() method of a controller or task command.

Resource groups

A resource group identifies a set of related resources. A resource group can include business objects such as a contract or a set of related commands. In access control, resource groups specify the resources to which the access control policy authorizes access.

Resource groups are defined in the ACRESGRP table. Site Administrators can manage resource groups and associate resources with resource groups using the Administration Console, or by using XML.

Implicit resource groups

Implicit resource groups define resources that match a certain set of attributes. One of these attributes must be the Java class name. Other attributes may include status, store ID, price, and so on. For example, you could create an implicit resource group that includes all orders that have pending status (ORDERS.STATUS=P). Implicit resource groups are usually used for grouping resources that will be used in resource-level policies, when the resources share a common attribute beyond the Java class name.

Implicit resource groups are defined using the CONDITIONS column of the ACRESGRP table. Simple implicit resource groups can be created using the Administration Console. Increasingly complex groups can be created using XML.

Explicit resource groups

Explicit resource groups are specified by associating one or more resource categories to a resource group. This association is done in the ACRESGPRES table. Adding a resource category to a group explicitly, by listing its Java class name, lets you group individual resources that might not necessarily share common attributes.

Relationships

Each resource may have some kind of relationship associated with it, and a set of members that fulfill each relationship. For example, all resources have a relationship of owner, which is fulfilled by the owner of the resource. Other relationships can include recipients of documents and the creator of an order. These resource relationships are important in determining who can perform certain actions on a particular instance of a resource. For example, the creator of a document may not be able to delete it, but perhaps an auditor may. Similarly, a reviewer may only be able to read and approve a document, but not forward it or perform other operations.

Relationships are stored in the ACRELATION table, and are optionally specified in an access control policy, using the ACRELATION_ID column of the ACPOLICY table. When evaluating a policy that requires the fulfillment of a relationship between the user and the resource, the fulfills (Long Member, String relationship) method on the resource will be called to evaluate it. When comparing these relationships to relationship groups, these relationships are sometimes referred to as simple relationships.

Relationship groups

Access control policies can specify that a user must fulfill a particular relationship with respect to the resource being accessed, or they can specify that a user must fulfill the conditions specified in a relationship group. In most cases, a relationship is sufficient. However, if more complex relationships are needed, a relationship group can be used instead. A relationship group allows you to specify multiple relationships and also a chain of relationships. Both of these are done using a relationship chain construct. A relationship chain is a construct that can express a simple relationship (directly between a user and the resource), but can also be used to express a series of relationships between the user and the resource. For example, in order to express that a user must have a role in an organization that has a relationship (other than the owner relationship) with the resource, one must use a relationship group. In this example, there is a role relationship between the user and the organization, and a relationship between the organization and the resource.

Comparing relationships and relationship groups

In most cases, using a relationship should satisfy the access control requirements for your application since, conceptually, most relationships are directly between a user and the resource. For example, the policy states that the user must be the creator of the resource. If however, you need to specify multiple relationships, a relationship group should be used. For example, the policy states that the user must be the creator or the submitter of the resource.

Relationship groups are also needed to express a chain of relationships between a user and the resource. In a chain of relationships, there is no direct relationship between the user and the resource for example, a user belongs to the buying organization specified by an order. In this case, the user has a child relationship with the organization, and that organization has a buying relationship with the order.

Relationship chains

<parameter name= "X" value="Y"/>

<openCondition name="RELATIONSHIP_CHAIN">
<parameter name="RELATIONSHIP"
value="aValue"/>
</openCondition>

For relationship chains of length one, the <parameter name="Relationship" value="something"> element specifies a direct relationship between the user and the resource. The value attribute is the string representing the relationship between the user and the resource. It must also correspond to the relationship parameter of the fulfills() method on the protectable resource.

When a relationship chain has a length of two, it is a series of two relationships. The first, <parameter name= "X" value="Y"/>, element is between a user and an organizational entity. The last, <parameter name= "X" value="Y"/>, element is between that organizational entity and the resource. The following is an example of a relationship chain with a length of two.

<openCondition name=RELATIONSHIP_CHAIN">
<parameter name="aValue1" value="aValue2"/>
<parameter name="RELATIONSHIP" value="aValue3"/>
</openCondition>

The aValue1 possible values include HIERARCHY and ROLE. HIERARCHY specifies that there is a hierarchical relationship between the user and the organizational entity in the membership hierarchy. ROLE specifies that the user plays a role in the organizational entity.

If the value of aValue1 is HIERARCHY, the possible values include child, which returns the organizational entity for which the user is a direct child in the member hierarchy. If the value of aValue1 is ROLE, possible values include any valid entries in the NAME column of the ROLE table which return all of the organizational entities for which the current user plays this role.

The aValue3 entry, is a string representing the relationship between one or more organizational entities retrieved from evaluating the first parameter and the resource. This value corresponds to the relationship parameter of the fulfills() method on the protectable resource. If more than one organizational entity was returned by evaluating parameter aValue1 , this part of the RELATIONSHIP_CHAIN is satisfied if at least one of these organizational entities satisfies the relationship specified by parameter aValue2.

Types of access control policies

There are two types of access control policies:

• Groupable standard policies (policy type -2)
• Groupable template policies (policy type -3)

Both groupable template and groupable standard policies must belong to a policy group in order to be applied in the system. A groupable standard policy is applied, once, at organizations that subscribe to a policy group that contains the policy.

Groupable template policies are dynamic in nature in that they have an access group that is scoped, when the system is running, to the organization that owns the resource. For example, when this type of policy is applied to a resource owned by Organization XYZ, it would check if the user played one of the specified roles for Organization XYZ or its ancestors.

Special default access control policies

The following policies require some extra explanation:

• Site Administrators Can Do Everything (SiteAdministratorsCanDoEverything)
• BecomeUser Customer Service Group Executes Become User Commands on customer's behalf (BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup)

The SiteAdministratorsCanDoEverything policy, is a special default policy that grants super-user access to administrators with the Site Administrator role. In this policy, a Site Administrator can perform any action on any resource, even if those actions or resources have not been defined. It is important to be aware of this when assigning this role to users.

BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup policy is a special policy that allows certain administrative users to run specified commands on behalf of other users. This policy is needed, for example, when a customer requests a customer service representative to create an order on his behalf. In this case, the customer service representative is able to run the command such that it appears like the customer himself has run the command.