IBM



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. 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 should 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 perform any resource-level checking.

The command calls checkIsAllowed(Object Resource, String Action). In cases where the command writer does not know which resources should be checked when getResources() is called by the Runtime, the command can call this checkIsAllowed() method, as needed, to determine whether the current action and resource pair are 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: As explained above, 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 data bean manager's activate() method, the WebSphere Commerce Runtime will ensure that there is a policy that grants the current user the authority to perform the Display action on the primary data bean resource.


Redbooks
ibm.com/redbooks


+

Search Tips   |   Advanced Search