Monday, 30 June 2014

Websphere Commerce Access Control Policies Part1






Access Control Policy is enforced by the access control policy manager. when a user attempts to access a protected resource, ACP manager determines what ACP are applicable for that protected resource, and based upon the applicable ACP, it determines if the user is allowed to access the requested resources.

There are two level/types of Access Control Policies.

1. Command-level Access Control Policy 
2. Resource-level Access Control Policy

1. Command-level Access Control Policy 

Command level access control policy checks who can do what in the current store Also known as ‘role-based’ access control, for example:All sellers can execute seller commands.
Command-level check on controller commands: 
Policy to all Execute action on command resource (For e.g. interface)generally targeting single role (i.e. Sellers).
Command-level check on views: 
Done if view called direct from URL or a redirect from command. Action is the view name.

2. Resource-level Access Control Policy 

Checks who can execute what command on which resources in the current store, for example:Only display data from Order which you create.Only modify promotion in organization which you play a role.
Resource-level check done on command if:
1. Command implements getResources() method.
2. Command’s perform Execute calls checkIsAllowed() method.
Resource-level check done on beans: 

If bean invoked by Data bean Manager’s activate() method.Ensures there is a policy which grants the user authority to perform the Display action on the primary data bean resource.
 
An Access Control is a 4-element that is stored in the ACPOLICY table as described below.


1.Member (Access/User) group (For eg: Registered Customers) 
Group of users to which the policy applies (implicit and explicit grouping of users)


2.Action group(For eg: Group must contain OrderItemAddCmd) 
A group of actions performed by the user on resources


3.Resource group(For eg: Target resource of command, Order Bean 
Objects like an order, or a set of related commands such as all the commands that users of a particular role can perform.


4.Relationship (For eg: User must be creator of the Order Bean) 
Relationship between the user and the resource.


1. Access Group/User Group 
The user group is a specific type of member group that is defined in the MBRGRP table. A user group must be associated with member group type of -2. The value of -2 represent an access group and is defined in the MBRGRPTYPE table Association between the user group and member group type is stored in the MBRGRPUSG table.

The membership of a user into a particular user group may be stated explicitly or implicitly. An explicit specification occurs if the MBRGRPMBR tables states that user belongs to a particular member group. An implicit specification occurs if the user satisfies a condition that is stated in the MBRGRPCOND table.


2. Action Group 
The ActionGroup elements come from the ACACTGRP table. An action group refers to an explicitly specified group of actions. The list of actions is stored in the ACACTION table and the relationship of each action to its action group (or group) is stored in the ACACTACTGP table.For E.g "OrderWriteCommands" action group. This action group includes the following action that are used to update orders.

OrderDeleteCmd
OrderCancelCmd
OrderAProfileUpdateCmd
OrderUnlockCmd
OrderScheduleCmd
ScheduledOrderCancelCmd
ScheduledOrderProcessCmd
OrderItemAddCmd
OrderItemDeleteCmd
OrderItemUpdateCmd
PayResetPMCmd

3. Resource Group 
The resource group is mechanism to group together particular types of resources. Membership of a resource in a Resource Group can be specified in one of two ways. Either using the conditions column in the ACRESGRP table or using the ACRESGPRES table.In most case, it is sufficient to use the ACRESGPRES table for associating resources to resource group. Using this method, resources are defined in the ACRESCGRY table suing their java class name. These resources are associated with appropriate resource group(ACRESGRP) using the ACRESGPRES association table.


4. Relationship 
The Access Control Policy can optionally include either a Relationship or Relationship Group element as its fourth element. If ACP uses a Relationship element, this comes from the ACRELATION table. On other hand, it includes a Relationship Group Element that comes from the ACRELGRP table. A Relationship Group specification from the ACRELGRP table takes precedence over the Relationship information from the ACRELATION table.

Access control Policy can be loaded using two methods

1.Using SQL Approach (Running SQL Directly).

2.Using ACPLOAD utility .

Loading AC policy using SQL approach for the newly created Command

insert into acrescgry (ACRESCGRY_ID,RESCLASSNAME) values ((select counter from keys where tablename='acrescgry'),'com.sample.commands.TestCmd');

insert into acresact (ACRESCGRY_ID, ACACTION_ID) values ((select counter from keys where tablename='acrescgry'),(select ACACTION_ID from acaction where action='Execute'));

insert into acresgpres (ACRESGRP_ID, ACRESCGRY_ID) values ((select ACRESGRP_ID from acresgrp where MEMBER_ID in (select orgentity_id from orgentity where orgentityname='Root Organization') and GRPNAME='AllSiteUserCmdResourceGroup'), (select counter from keys where tablename='acrescgry'));

update keys set counter=counter+1 where tablename =’acrescgry’; 

Loading AC policy using SQL approach for the newly created View

insert into acaction (acaction_id, action) values ((select counter from keys where tablename='acaction'), 'TestView');
insert into acactactgp (ACACTGRP_ID,ACACTION_ID) values ((SELECT ACACTGRP_ID FROM ACACTGRP WHERE GROUPNAME = 'AllSiteUsersViews' and member_id in (select orgentity_id from orgentity where orgentityname='Root Organization') ), (select acaction_id from acaction where action='TestView'));
update keys set counter=counter+1 where tablename ='acaction';


If you are not going by SQL Query approach you can follow the below method to load access control policy for view


View AC Policy Example

Create an AC Policy file named TestViewAcPolicy.xml .

<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE Policies SYSTEM "../dtd/accesscontrolpolicies.dtd">
<Policies>
<Action Name="ExecuteCommand" CommandName="Execute"></Action>
<Action Name="AccordianPaneView" CommandName="AccordianPaneView"/>
<Action Name="AccordianBillingAddressDisplayView" CommandName="AccordianBillingAddressDisplayView"/>
<ActionGroup Name="AllSiteUsersViews" OwnerID="RootOrganization">
<ActionGroupAction Name="AccordianPaneView"/>
<ActionGroupAction Name="AccordianBillingAddressDisplayView"/>
</ActionGroup>
</Policies>

Run ACPLOAD in Toolkit


Go to C:\IBM\WCDE_ENT70_Latest\xml\policies\xml.
Keep TestViewAcPolicy.xml in the folder .Go to C:\IBM\WCDE_ENT70_Latest\bin (Toolkit installation directory\bin).Run the below command (Derby DB)

ACPLOAD TestViewAcPolicy
It will create another two files if runs successfully as shown below

1. TestViewAcPolicy_xmltrans((Xml tranformed file for Id Resolver utility)
2. TestViewAcPolicy_idres( Id resolved file  used for mass load)

Please see the below screen for tables getting updated

  Webshere commerce Access Control





If you are not going by SQL Query approach you can follow the below method to load access control policy for the command

Create an AC Policy file named TestCommadAcPolicy.xml  

<?xml version="1.0" encoding="ISO-8859-1" standalone="no" ?>
<!DOCTYPE Policies SYSTEM "../dtd/accesscontrolpolicies.dtd">
<Policies>
<Action Name="ExecuteCommand"  CommandName="Execute">
</Action>
<ResourceCategory Name="com.ibm.commerce.sample.commands.TestControllerCmdResourceCategory"
ResourceBeanClass="com.ibm.commerce.sample.commands.TestControllerCmd">
<ResourceAction Name="ExecuteCommand"/>
</ResourceCategory>
<ResourceCategory Name="com.ibm.commerce.sample.commands.SampleControllerCmdResourceCategory"
ResourceBeanClass="com.ibm.commerce.sample.commands.SampleControllerCmd">
<ResourceAction Name="ExecuteCommand"/>
</ResourceCategory>       
<ResourceGroup Name="AllSiteUserCmdResourceGroup"  OwnerID="RootOrganization">
<ResourceGroupResource Name="com.ibm.commerce.sample.commands.TestControllerCmdResourceCategory"/>
<ResourceGroupResource Name="com.ibm.commerce.sample.commands.SampleControllerCmdResourceCategory"/>
</ResourceGroup>
</Policies>

Run ACPLOAD in Toolkit

Go to directory C:\IBM\WCDE_ENT70_Latest\xml\policies\xml. Keep TestCommadAcPolicy.xml in that directory .Go to directory C:\IBM\WCDE_ENT70_Latest\bin(Toolkit installation directory\bin)
Run the below command (Derby DB)

ACPLOAD TestCommadAcPolicy

It will create another  two files if runs successfully

1.TestCommadAcPolicy_xmltrans(Xml tranformed file for id resolver utility)
2.TestCommadAcPolicy_idres ( Id resolved file  used for mass load)

Please see the below screen for tables getting updated

Webshere commerce Access Control












Read the post on Websphere Commerce Access Control Policies Part2    for more details.