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.

• Implementing access control in enterprise beans
  If you create new enterprise beans that require protection by access control policies, there are several steps follow.

• Implementing access control in data beans
  If a data bean is to be protected, it can either be directly, or indirectly protected by access control policies. If a data bean is directly protected, then there exists an access control policy that applies to that particular data bean. If a data bean is indirectly protected, it delegates protection to another data bean, for which an access control policy exists.

• Implementing access control in controller commands
  When creating a new controller command, the implementation class for the new command should extend the com.ibm.commerce.commands.ControllerCommandImpl class and its interface should extend the com.ibm.commerce.command.ControllerCommand interface.

• Implementing access control policies in views
  Resource-level access control for views is performed by the data bean manager. The data bean manager is invoked in the following cases: When the JSP template includes the <useBean> tag and the data bean is not in the attribute list. When the JSP template includes the following activate method: DataBeanManager.activate(xyzDatabean, request);

Related concepts

Protectable interface
Authorization