Enforcing access control

Policy Manager is the access control component that determines whether the current user is allowed to execute the specified action on the specified resource. Access control policies are specified in XML format. During instance creation, the default policies and policy groups are loaded into the appropriate database tables. When WebSphere Commerce Application Server is started up, the access control information is cached in memory so the Policy Manager can quickly check a user's authorization when called to do so. If access control information is changed in the database through the Administration Console, or by loading XML policy data, the access control cache needs to be updated. We can update the cache by updating the appropriate registry in the Administration Console. If policy data is changed, then update the Access Control Policies registry. If policy group data is changed, update the Access Control Policy Groups registry. Restarting WebSphere Commerce also updates the cache.

When a user attempts to acts on a protected resource, an access control check occurs to make sure that the user is authorized. The Policy Manager looks for all the access control policies that apply to the organization that owns the resource. Then, it checks those policies to evaluate if the user is authorized to act on the target resource. If there is at least one such policy, the Policy Manager grants access, otherwise, access is denied.

Levels of access control

There are two broad levels of access control in WebSphere Commerce: command level (also know as role-based) and resource level (also known as instance-level).

Command-level or role-based access control

Command-level or role-based access control is coarse access control. It determines who can do what in the current store. With role-based access control, we can specify that all users of a particular role can execute certain commands within the current store. If no store is selected, then role checking is not scoped to any particular store or organization. Consider the access control policy, Sellers can execute sellers commands. In this policy, one of the sellers commands is the CatalogUpdate command. In the preceding figure, Jack and Tom both are sellers, so both of them can run the UpdateCatalog command. However, they can only run this command if the current store belongs to an organization where they play the seller role.

Role-based access control is used for controller commands and views. This type of access control considers only the current store, not any of the other low level resources. It determines only whether the user is allowed to execute a particular controller command or view. This level of access control is mandatory and is enforced by the run time.

Command-level access control for controller commands

Whenever you run a controller command, an access control policy must exist that grants users to perform the Execute action on the command resource. The resource is the interface name of the controller command. The access group is typically geared to a single role. For example, we can specify that users with the Account Representative role can execute any command in the AccountRepresentativesCmdResourceGroup resource group.

Command Level Access Control for views

When a view is called directly from the URL, or is the result of a redirect from a command, it must have an access control policy. Such a policy must have the viewname specified as an action, in the ACACTION table. This action must then be associated with an action group using the ACACTACTGP table. This action group must then be referenced in the appropriate command level policy, in the ACPOLICY table.

Instance-level or resource-level access control

Instance-level or resource-level access control policies provide granular access control, determining who can do what command on which resources in the current store. Sellers can modify objects that are owned by the organization for which they play their role. For example, If user A has the seller role for Seller Organization 1 and user B has the seller role for Seller Organization 2. User A creates a furniture category at the furniture store. User B creates a shirt category at the shirt store. User A can modify the furniture category, but not the shirt category. User B can modify the shirt category, but not the furniture category.

To summarize, first the system does a command-level access check. If the user is allowed to execute a command, a subsequent resource-level access control policy is done to determine if the user can access the resource in question.

Resource level access control applies to commands and data beans.

Resource-level access control for commands

After the command level access control checking is completed, if access is granted, then resource level checking is done in one of the following two cases:

• The command implements getResources() - this method specifies the instances of resources that need to be checked against the current action; where the command is now the action. The WebSphere Commerce runtime enforces that the current user has access to all of the resources specified by getResources(). By default, getResources() returns null, that is, it does not check resource level access.

• The command calls checkIsAllowed(Object Resource, String Action) - in cases where the command writer does not know which resources need to be checked at the time that getResources() is called by the Runtime, the command can call this checkIsAllowed() method, as needed to determine whether the current action and resource pair is authorized. The action is usually the interface name of the current command. When this method is called, if access is denied, an exception is thrown: ECApplicationException( ECMessage._ERR_USER_AUTHORITY, ..)

Resource level access control for data beans

Views are protected by command level policies, which are usually based on roles. For example, the command level policy might specify that a Seller Administrator has access to a specific view. It is often necessary to further ensure that the data beans on the JSP are all related to the organization for which the user plays the Seller Administrator role. This is done by having all data beans that need protection (directly or indirectly), implement the Delegator interface. These data beans delegate to a primary (independent) data bean, which in turn implements the Protectable interface. A primary data bean delegates to itself and implement both interfaces. Whenever a data bean is invoked with the data bean manager's activate() method, the WebSphere Commerce runtime ensures that there is a policy that grants the current user the authority to perform the Display action on the primary data bean resource.

Related concepts
Authorization

Related tasks
Customizing default access control policies
Defining access control policy elements using XML
Implementing access control

Related reference
Examples: Customize access control policies using the Organization Administration Console