Implementing access control

This topic describes how to implement access control in customized code. In general, enterprise beans and data beans are resources that you may want to protect. However, not all enterprise beans and data beans should be protected. Within the existing WebSphere Commerce application, resources that require protection already implement the protectable interface. Typically, the question of what to protect comes into play when you create new enterprise beans and data beans. Deciding which resources to protect depends upon your application.

If a command returns an enterprise bean in the getResources method, then the enterprise bean must be protected because the access control policy manager will call the getOwner method on the enterprise bean. The fulfills method will also be called if a relationship is specified in the corresponding resource-level access control policy.

If you were to implement the protectable interface (and therefore, put the resource under protection) for all of your own enterprise beans and data beans, the application could require many policies. As the number of policies increases, performance may degrade and policy management becomes more challenging.

A theoretical distinction is made between primary resources and dependent resource. A primary resource can exist upon its own. A dependent resource exists only when its related primary resource exists. For example, in the out-of-the-box WebSphere Commerce application code, the Order entity bean is a protectable resource, but the OrderItem entity bean is not. The reason for this is that the existence of an OrderItem depends upon an Order -- the Order is the primary resource and the OrderItem is a dependent resource. If a user should have access to an Order, it should also have access to the items in the order.

Similarly, the User entity bean is a protectable resource, but the Address entity bean is not. In this case, the existence of the address depends on the user, so anything that has access to the user, should also have access to the address.

Primary resources should be protected, but dependent resources often do not require protection. If a user is allowed to access a primary resource, it makes sense that, by default, the user should also be allowed to access its dependent resources.

Related concepts

Protectable interface
Authorization