Enforcing access control

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, you 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, you 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 by 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.