Understanding 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 your 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 WAS 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 WAS.
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 your 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 your 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.
Related concepts
Protectable interface
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
Implementing access control
Create an access control policy
Related reference
Access control data model
Access logging data model