Implement 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.


Task info

To determine if a data bean should be protected, consider the following:

  1. Is the information in the data bean information that requires protection? For example, is it something of a private nature? If not, direct protection by access control is not required. If it is, you need to implement access control for the data bean.

  2. Will the view instantiate the data bean by using information from some input parameter? In this case, due to the fact that we are not certain that access control has already determined whether the user is allowed access to this information, you should protect the new data bean.

  3. Data beans are instantiated by views. Will the view instantiate the data bean using the userID and storeID from the command context? If yes, and access control has already determined that access is allowed, directly protecting this data bean would not be required. If not, implement access control for the data bean.

If we create a new data bean that is to be directly protected by an access control policy, the data bean must do the following:


Procedure

  1. Implement the com.ibm.commerce.security.Protectable interface. As such, the bean must provide an implementation of the getOwner() and fulfills(Long member, String relationship) methods. When a data bean implements the Protectable interface, the data bean manager calls the isAllowed method to determine if the user has the appropriate access control privileges, based upon the existing access control policies. The isAllowed method is described by the following code snippet: 

      isAllowed(Context, "Display", protectable_databean);

    where protectable_databean is the data bean to be protected.

  2. If resources that the bean interacts with are grouped by an attribute other than the resource's Java class name, the bean must implement the com.ibm.commerce.grouping.Groupable interface.

  3. Implement the com.ibm.commerce.security.Delegator interface. This interface is described by the following code snippet: 

      Interface Delegator {
        Protectable getDelegate();
}

    Note: In order to be directly protected, the getDelegate method should return the data bean itself (that is, the data bean delegates to itself for the purpose of access control).


Results

The distinction between which data beans should be protected directly versus which should be protected indirectly is similar to the distinction between primary and dependent resources. If the data bean object can exist on its own, it should be directly protected. If the existence of data bean depends upon the existence of another data bean, then it should delegate to the other data bean for protection.

An example of a data bean that would be directly protected is the Order data bean. An example of a data bean that would be indirectly protected is the OrderItem data bean. If we create a new data bean that is to be indirectly protected by an access control policy, the data bean must implement the com.ibm.commerce.security.Delegator interface. This interface is described by the following code snippet:

Note: The data bean returned by getDelegate must implement the Protectable interface.

If a data bean does not implement the Delegator interface, it is populated without the protection of access control policies.


Related concepts
Protectable interface
Authorization


Related tasks
Implementing access control
Protecting data beans