Understand access control
Access control in a WebSphere Commerce application is composed of the following elements: users, actions, resources, and relationships.
- Users are the people that use the system. For access control purposes, users must be grouped into relevant access groups. One common attribute that is used to determine membership of an access group is roles. Roles are assigned to users on a per organization basis. For more information about roles, see Roles. Some examples of access groups include registered customers, guest customers, or administrative groups like customer service representatives.
- Actions are the activities that users can perform on the resource. For access control purposes, actions must also be grouped into relevant action groups. For example, a common action used in a store is a view. A view is invoked to display a store page to customers. The views used in the store must be declared as actions and assigned to an action group before they can be accessed.
- Resources are the entities that are protected. For example, if the action is a view, the resource to be protected is the command that invoked the view, for example com.ibm.commerce.command.ViewCommand. For access control purposes, resources are grouped into resource groups.
- Relationships are the relationship between the user and the resource. Access control policies may require that a relationship between the user and the resource be satisfied. For example, users may only be allowed to display the orders that they have created.
In a WebSphere Commerce application, there are two main levels of access control. The first level of access control is performed by the WebSphere Application Server. In this respect, WebSphere Commerce uses WebSphere Application Server to protect enterprise beans and servlets. The second level of access control is the fine-grained access control system of WebSphere Commerce.
The WebSphere Commerce access control framework uses access control policies to determine if a given user is permitted to perform a given action on a given resource. This access control framework provides fine-grained access control. It works in conjunction with, but does not replace the access control provided by the WebSphere Application Server.
Types of access control
There are two types of access control, both of which are policy-based: command-level access control and resource-level access control.
Command-level (also known as "role-based") access control uses a broad type of policy. You can specify that all users of a particular role can execute certain types of commands. For example, you can specify that users with the Account Representative role can execute any command in the AccountRepresentativesCmdResourceGroup resource group. Or, as depicted in the following diagram, another example policy is to specify that all seller administrators can perform any action specified in the SellerAdministratorsViews Group on any resource that is specified by the ViewCommandResourceGroup.
Note: The XML information for the Conditions column of the MBRGRPCOND table is generated when you use the Administration Console to set up the access groups.
A command-level access control policy always has the ExecuteCommandActionGroup as the action group for controller commands. For views, the resource group is always ViewCommandResourceGroup.
All controller commands must be protected by command-level access control. In addition, any view that can be called directly, or that can be launched by a redirect from another command (in contrast to being launched by forwarding to the view) must be protected by command-level access control.
Command-level access control determines whether the user is allowed to execute the particular command within the store you have specified. If a policy allows the user to execute the command, a subsequent resource-level access control policy could be applied to determine if the user can access the resource in question.
Consider when a seller administrator attempts to perform an administrative task. The first level of access control checking determines if this user is allowed to execute the particular seller administration command within the current store. The user is allowed to run the command if the command belongs to the ViewCommand resource group, and the user has the Seller Administrator role in the current store's organization. If this is true, the command may then trigger a resource-level access control check if needed. In order to satisfy this check, a resource-level policy would have to grant access. Such a policy may state that seller administrators are only permitted to perform administrative tasks on resources that are owned by the organization for which the user is a seller administrator.
To summarize, in command-level access control the "resource" is the command itself and the "action" is to execute the command within the current store. The access control check determines if the user is permitted to execute the command within the current store. By contrast, in resource-level access control the "resource" is any protectable resource that the command or bean accesses and the "action" is the command itself.
Other access control concepts
WebSphere Commerce allows you to determine, through access control, which tasks a particular user, be they customers, buyers, administrators, distributors, manufacturers, or suppliers, can perform in relation to the business.
To facilitate database management and ensure security, access to WebSphere Commerce must be restricted to specific individuals and organizations. The process of restricting access is referred to as access control or authorization. Authorization can be defined as security guidelines that:
- Allow or deny a user of a system access to the resources managed by a system.
- Specify what actions the user can perform on each resource.
The authorization model for WebSphere Commerce is based upon the enforcement of access control policies. 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 user and then, based upon the applicable access control policies, it determines if the user is allowed to perform the requested operation on the given resource.
The Site Administrator manages the access control policies that apply to a site or store.
- Protectable interface
A key factor for having a resource protected by the WebSphere Commerce access control policies, is that the resource must implement the com.ibm.commerce.security.Protectable interface. This interface is most commonly used with enterprise beans and data beans, but only those particular beans that require protection need to implement the interface.
- Resource protection in WebSphere Application Server
The following WebSphere Commerce resources are protected under access control by WebSphere Application Server:
- Administrator authority to act for a registered customer
An administrator can act on behalf of a registered customer for multiple requests in a session by running the RunAsUserSetInSession URL. If an administrator has the required authority to act on behalf of a registered customer, the administrator can assume the identity for that customer for all subsequent requests. By default, the administrator running on behalf of a registered customer can perform all actions that the registered customer can perform. While acting on behalf of a registered customer, the administrator cannot run any administrative commands.
- Access control interactions
This section presents an interaction diagram showing how access control works in the WebSphere Commerce access control policy framework.
- Groupable interface
The application of an access control policy is specific to a group of resources. Resource groupings can be made based upon attributes such as the class name, the state of an order or the storeId value.
- 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.
- Implement access control
This topic describes how to .mplement access control in customized code. In general, enterprise beans and data beans are resources that you may want to protect. However, not all enterprise beans and data beans should be protected. Within the existing WebSphere Commerce application, resources that require protection already implement the protectable interface. Typically, the question of what to protect comes into play when you create new enterprise beans and data beans. Deciding which resources to protect depends upon the application.
- Modify access control on existing WebSphere Commerce resources
This section guides you through modifying access control on existing WebSphere Commerce resources. In particular, the following scenarios are reviewed:
Related concepts
Consumer direct access control structure
Advanced B2B direct access control structure
Demand Chain - channel hub organization structure
Supply Chain - supplier hub organization structure
Extended Sites - extended sites hub organization structure
Related tasks
Create an access control policy
Related reference