Implement access control

This topic describes how to implement access control in customized code. In general, enterprise beans and data beans are resources that we 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 creating new enterprise beans and data beans. Deciding which resources to protect depends upon your application.


Task info

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 our own enterprise beans and data beans, your 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.


See


Related concepts
Groupable interface
WebSphere Commerce access control policies
Protectable interface
Understand access control
Authorization


Related tasks
Modifying access control on existing WebSphere Commerce resources
Implementing access control in enterprise beans
Implementing access control in controller commands
Implementing access control in data beans
Implementing access control policies in views
Deploying access control policies


Related reference
Sample: Access control policies for development purposes
Sample: Command-level access control policy for new controller commands
Sample: Access control policy for new views
Sample: Resource-level access control policy for a new entity bean