Understanding access control
Access control in a WebSphere Commerce application is composed of the following elements:
| Users | The people that use the system. Users are grouped into access groups. One common attribute used to determine membership of an access group is roles, which are assigned to users on a per organization basis. Examples of access groups include registered customers, guest customers, or administrative groups like customer service representatives. |
| Actions | Activities performed on the resource. Actions are grouped into 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 | Protected entities. 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 | 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...
- Access control performed by the WebSphere Application Server to protect enterprise beans and servlets.
- 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 (also known as "role-based") access control uses a broad type of policy. We can specify that all users of a particular role can execute certain types of commands. For example, we can specify that users with the Account Representative role can execute any command in the AccountRepresentativesCmdResourceGroup resource group.
With resource-level, we can, for example specify that all seller administrators in the SellerAdministratorsViews Group can perform actions on resources specified by the ViewCommandResourceGroup.
The XML information for the Conditions column of the MBRGRPCOND table is generated when using 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 us 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.
See
- Protectable interface
- Resource protection in WebSphere Application Server
- Administrator authority to act for a registered customer
- Access control interactions
- Groupable interface
- WebSphere Commerce access control policies
- Implementing access control
- Modify access control on existing WebSphere Commerce resources
- Control access for WebSphere Commerce Accelerator
Related concepts
Groupable interface
WebSphere Commerce access control policies
Access control implications when a controller command is extended
Protectable interface
B2C access control structure
Extended Sites - extended sites hub organization structure
Resource protection in WebSphere Application Server
Related tasks
Implementing access control
Creating an access control policy
Deploying access control policies
Related reference
Access logging data model
Sample: Access control policies for development purposes
Sample: Command-level access control policy for new controller commands
Sample: Access control policy for new views
Sample: Resource-level access control policy for a new entity bean