Enforcing access control

Policy Manager is the access control component that determines whether or not 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. This can be done by updating the appropriate registry in the WebSphere Commerce Administration Console. If policy data has changed, then the Access Control Policies registry should be updated. If policy group data has changed, then the Access Control Policy Groups registry should be updated. Restarting WebSphere Commerce will also result in updating the cache.

When a user attempts to perform an action on a protected resource, an access control check will be done 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 perform the action 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, you can specify that all users of a particular role can execute certain commands within the current store. If no store has been 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 ModifyAuction command. In the preceding figure, Jack and Tom both are sellers, so both of them can modify auctions. 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 only considers the current store, not any of the other low level resources. It only determines if 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 usually 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, 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. The previous example of a role-based access control policy that allows Sellers to modify auctions, can be fine-tuned for resource-level access control. Sellers can modify auctions owned by the organization for which they play their role. For example, Jack has the seller role for Seller Organization 1. Tom has the seller role for Seller Organization 2. Jack creates a furniture auction at the furniture store. Tom creates a shirt auction at the shirt store. Jack can modify the furniture auction, but not the shirt auction. Tom can modify the shirt auction, but not the furniture auction.

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 has been completed, if access has been 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 will enforce that the current user has access to all of the resources specified by getResources(). By default, getResources() returns null, that is, it does not perform any resource level checking.

• 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 if 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 will be 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 may 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 would delegate to itself, and therefore implement both interfaces. Then, whenever a data bean is invoked using the Databean Manager's activate() method, the WebSphere Commerce Runtime will ensure that there is a policy which 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
Define access control policy elements using XML
Implementing access control

 

Related Reference

Examples: Customizing access control policies using the Organization Administration Console