Access control implications when a controller command is extended

According to the WebSphere Commerce programming model, we can create our own implementations of existing controller commands. In this case, you create a new implementation class and then associate the new implementation class to the existing interface by updating the command registry.

There are three potential access control-related implications of performing such an extension:

1. Effect on the getResources method.

2. Effect on the command-level access control policies

3. Effect on the resource-level access control policies

Effect on the getResources method

If we are extending an existing controller command, meaning that the existing logic of the command will be performed as well as your new customized logic, your new command will subclass from the existing command. The performExecute method of the new implementation calls the performExecute method of the superclass. If your new command does not access any new resources that require protection, you do not have to override the getResources method. However, if new protectable resources are accessed, the new command should implement its own getResources method and in this method call the getResources method from the superclass, before implementing our own getResources logic.

The results of the getResources method from the superclass should be stored in a private instance variable of type AccessVector. The results of the local getResources method should then be appended to the end of this vector. For example, the new implementation class would contain code similar to the following pseudo-code:

private AccessVector resources = null;

public AccessVector getResources() throws ECException {
 // First, get the resources from the original implementation
 resources = super.getResources();

 // Now, append the new resources

 ////////////////////////////////////////
 // Logic for getting new resources //
 // and appending to the vector.  //
 /////////////////////////////////////////

 return resources;
}

If we are not extending the logic of an existing controller command, but instead we are replacing the logic completely, you would not call the super.performExecute method in your new implementation. You would then not need to call the super.getResources method from within our own implementation. Instead, just implement our own getResources method, as appropriate.

Effect on the command-level access control policies

Command-level policies for controller commands consist of the "Execute" action operating on the command resource. The command resource is specified by its interface name. When you extend an existing command, the command still implements the original interface, and as such, the existing command-level policy is sufficient to maintain the previous command-level access control. Therefore, no changes are required.

Effect on the resource-level access control policies

If you have created a new implementation of an existing command and associated this implementation to the interface of that existing command, changes are not required in the resource-level access control policies.

If instead you create a new implementation class that extends an existing implementation and in this class you call the super.performExecute method and you also implement a new interface, then changes are required in resource-level access control policies.

In this latter case, if the new command implements the getResources method or inherits a non-trivial implementation of the getResources method from the base command, resource-level policy changes are required. Typically, resource-level policies consist of the command action operating on the business object resource. Since the action is simply a string representation of the command's interface, the new command generally needs to be added to the action groups of the base command. However, if the new command overrides the base implementation of getResources method by simply returning null, then no access control check will be done for this new command. Be aware that if this is not done carefully, this could potentially result in opening up the new command to malicious users.

When modifying the resource-level access control policies, the following are the high-level steps:

1. Locate the defaultAccessControlPolicies.xml file, which is found in the following directory:

   • (Developer) WCDE_installdir\Commerce\xml\policies\xml

2. Make a copy of this file. As an example, name the file myDefaultAccessControlPolicies.xml.

3. In this new file, define the new interface as a new action. For example, you would add the following:

   <Action Name="yourNewInterface"
            CommandName="yourNewInterface">
   </Action>

   where yourNewInterface is the name of the new interface.

4. Next, we must search through the file to locate all of the action groups to which the original action belonged and then add in your new action.

5. If the new command is operating on resources that were not previously specified by the base command, then the resource group of the corresponding access control policies must also be changed to accommodate the new resources.

6. Once you have completed our changes to the XML file, we can remove sections that you have not modified. Ensure that you keep the text before the <Policies> tag.

   For example, a command called MyOrderItemAddCmd which extends from an existing command called OrderItemAddCmd is being added. Since OrderItemAddCmdImpl implements getResources(), the new command must be defined as an action, then added to the action groups that OrderItemAdd belongs to:

   <?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
   <!DOCTYPE Policies SYSTEM "../dtd/accesscontrolpolicies.dtd">
   <Policies>
   <Action Name="com.xyz.MyOrderItemAddCmd"
   CommandName="com.xyz.MyOrderItemAddCmd">
   </Action>
   
   <ActionGroup Name="OrderCreateCommands" OwnerID="RootOrganization">
   <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
   </ActionGroup>
   
   <ActionGroup Name="OrderWriteCommands" OwnerID="RootOrganization"> 
   <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
   </ActionGroup>
   
   <ActionGroup Name="InterestItemReadCommands" OwnerID="RootOrganization">
   <ActionGroupAction Name="com.xyz.MyOrderItemAddCmd"/>
   </ActionGroup>
   </Policies>

7. Load the new policy information into the database.

Related concepts
Protectable interface
Understanding access control
WebSphere Commerce access control policies
Access control interactions
Groupable interface

Related tasks
Adding a new relationship to an existing WebSphere Commerce entity bean
Adding access control to an existing WebSphere Commerce entity bean that is not already protected