Develop > Persistence layer


Understand access control

Access control in a WebSphere Commerce application is composed of the following elements: users, actions, resources, and relationships.

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:

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

Implement access control

Create an access control policy

Related reference

Access control data model

Access logging data model


+

Search Tips   |   Advanced Search