Introduced in Feature Pack 2

Implementing access control

Introduced in Feature Pack 2

The content version service operates on all the nouns that are enabled for versioning. Access control policies are enabled to limit users to access content version services for a particular noun or group of nouns. For example, our previous Recipe Manager has the authority to create, delete, restore, change, and display the UI objects of Recipe and RecipeCollection, but does not have authority to perform the same actions on version service yet. In this lesson, you will learn how to create access control policy for version service on the new custom Recipe Manager role created in the previous recipe tutorial.

To allow the Recipe Manager to create, restore, delete, change, and display versions of the specified nouns, you need to define an action, an action group, a resource group, and a policy.

About this task

The following example is the completed Project-access-control.xml file containing the new code described in this task: Project-access-control.xml.

Procedure

  1. Navigate to the directory WCDE_installdir\xml\policies\xml.
  2. Open the Project-access-control.xml defined in the previous tutorial for editing.
  3. In the previous supported actions, add one more action for restore. the following is defined in the previous recipe tutorial:
    
    <!-- defining supported actions -->
    <!-- ================================================ -->
    
    
    <!-- read action (Get request) -->
    <Action Name="DisplayResourceAction" CommandName="Display"/>
    <!-- change action (Change request) -->
    <Action Name="ChangeResourceAction" CommandName="Change"/>
    <!-- process actions (Process request) -->
    <Action Name="AddResourceAction" CommandName="Add"/>
    <Action Name="DeleteResourceAction" CommandName="Delete"/>
    <Action Name="CreateResourceAction" CommandName="Create"/>
    add 1 more action in the end:
    <Action Name="RestoreResourceAction" CommandName="Restore" /> 
    An access profile is defined by an action.
  4. Define an action group. This contains all the access profiles the group can use
    <!--   AccessProfileActionGroup for Project-ContentVersion-ProjectGroupViewers -->
     	<ActionGroup Name="Project-ContentVersion-ProjectGroupViewers-AccessProfileActionGroup" OwnerID="RootOrganization">
    		<ActionGroupAction Name="GetContentVersion.IBM_Admin_Summary"/>
    	</ActionGroup>
    
    	<!-- Project-ContentVersion-RecipeManagers action group process action -->
    	<ActionGroup Name="Project-ContentVersion-ProjectManagers-ActionGroup" OwnerID="RootOrganization">
    		<ActionGroupAction Name="DisplayResourceAction"/>
    		<ActionGroupAction Name="CreateResourceAction"/>
    		<ActionGroupAction Name="DeleteResourceAction"/>
    		<ActionGroupAction Name="RestoreResourceAction"/>
    		<ActionGroupAction Name="ChangeResourceAction"/>
    	</ActionGroup>
  5. Define a resource group definition which provides the flexibility to protect resources of a particular state.

    For example, if you want to create a policy in which users can access the content version services of a particular object type, then you will need to define a resource group. The resource group limits the specified actions to the Project and ProjectCollection object types as shown:

    <!-- the ContentVersion protectable proxy -->
    <ResourceGroup Name="Project-ContentVersion-ResourceGroup"  OwnerID="RootOrganization">
    	<ResourceCondition>
    		<![CDATA[
    			<profile>
    				<andListCondition>
    					<orListCondition>
    							<simpleCondition>
    								<variable name="ObjectType"/>
    								<operator name="="/>
    								<value data="Project"/>
    							</simpleCondition>
    							<simpleCondition>
    								<variable name="ObjectType"/>
    								<operator name="="/>
    								<value data="ProjectCollection"/>
    							</simpleCondition>
    					</orListCondition>					
    					<simpleCondition>
    						<variable name="classname"/>
    						<operator name="="/>
    						<value data="com.ibm.commerce.content.facade.server.authorization.ContentVersionTypeProtectableProxy"/>
    					</simpleCondition>					
    				</andListCondition>
    			</profile>
    		]]>
    	</ResourceCondition>
    </ResourceGroup>
  6. Define a policy using the action group.
    <!-- the Project-ContentVersion-RecipeManagers access profile access policy -->
    	<Policy Name="Project-ContentVersion-ProjectManagers-AccessProfilePolicy"
          		OwnerID="RootOrganization"
    		UserGroup="ProjectManagersForOrg"
    		ActionGroupName="Project-ContentVersion-ProjectGroupViewers-AccessProfileActionGroup"
    		ResourceGroupName="AccessProfileResourceGroup"
    		PolicyType="groupableTemplate"	/>
    
    	<!-- the Project-ContentVersion-ProjectManagers policy -->
    	<Policy Name="Project-ContentVersion-ProjectManagers-Policy"
          		OwnerID="RootOrganization"
    		UserGroup="ProjectManagersForOrg"
    		ActionGroupName="Project-ContentVersion-ProjectManagers-ActionGroup"
    		ResourceGroupName="Project-ContentVersion-ResourceGroup"
    		PolicyType="groupableTemplate"	/>
    
    	<!--  defining policy groups -->
    	<PolicyGroup Name="ManagementAndAdministrationPolicyGroup" OwnerID="RootOrganization">
    		
    		<PolicyGroupPolicy 
    			Name="Project-ContentVersion-ProjectManagers-AccessProfilePolicy" 
    			PolicyOwnerID="RootOrganization"/>
    		<PolicyGroupPolicy 
    			Name="Project-ContentVersion-ProjectManagers-Policy" 
    			PolicyOwnerID="RootOrganization"/>
    	</PolicyGroup>
  7. Save the changes.
    The updated access profile xml file should resemble the included sample file..
  8. Stop the WebSphere Commerce test server.
  9. Run the acpload command to load the access control policy From a command prompt, navigate to WCDE_installdir\bin. Run the command: acpload Project-access-control.xml.
    For more information, see acpload utility.

Results