Develop > Persistence layer > Understand access control
Access control interactions
This section presents an interaction diagram showing how access control works in the WebSphere Commerce access control policy framework.
The preceding diagram shows actions that are performed by the access control policy manager. The access control policy manager is the access control component that determines whether the current user is allowed to execute the specified action on the specified resource. It determines this by searching through the policies in groups to which the resource owner subscribes. If the resource owner does not subscribe to any policy groups, it searches through the policies in groups to which the resource owner's closest ancestor subscribes. If at least one policy grants access, then permission is granted.
The following list describes the actions from the preceding interaction diagram. They are ordered from the top of the diagram to the bottom.
- isAllowed()
- The run-time components determine if the user has command-level access for either the controller command or view.
- getOwner()
- The access control policy manager determines the owner of the command-level resource. The default implementation returns the member identifier (memberId) of the owner of the store ( storeId) that is in the command context. If there is no store identifier in the command context, then the root organization (-2001) is returned.
- getAndApplyApplicablePolicies()
- The access control policy manager finds and processes the applicable policies, based on the specified user, action, resource, and current store. If a policy involves a role, and you specify a store, the policy manager evaluates whether the current user has the specified role in the specified store's organization. When a policy involves a role, and you do not specify a store, the policy manager evaluates whether the current user has the specified role in any organization. If at least one applicable policy grants access, the command-level access check passes, and the policy manager will continue to the next step to begin checking for resource-level authorization. Conversely, if none of the applicable policies grant command-level access, the policy manager returns at this point and denies access.
- validateParameters()
- Initial parameter checking and resolving.
- getResources()
- Returns an access vector that is a vector of resource-action pairs.
If nothing is returned, resource-level access control checking is not performed. If there are resources that should be protected an access vector (consisting of resource-action pairs) should be returned.
Each resource is an instance of a protectable object (an object that implements the com.ibm.commerce.security.Protectable interface). In many cases, the resource is an access bean.
An access bean may not implement the com.ibm.commerce.security.Protectable interface, however, the access control check can still occur as long as the corresponding enterprise bean is protected, according to the information included in Implement access control in enterprise beans.
The action is a string representing the operation to be performed on the resource. In most cases, the action is the interface name of the command.
- isAllowed()
- The run-time components determine if the user has resource level access to all of the resource-action pairs specified by getResources().
- getOwner()
- The resource returns the memberId of its owner. This determines which policies apply.
- getAndApplyApplicablePolicies()
- The access control policy manager searches for applicable policies and then applies them. If at least one policy per resource-action pair that grants the user permission to access the resource is found, then access is granted, otherwise access it is denied.
- fulfills()
- If an applicable policy has a relationship or relationship group specified, a check is done on the resource to see if the member satisfies the specified relationship, with respect to the resource.
- performExecute()
- The business logic of the command.
Related concepts