Access Control in WCS- Part2

Implementing access control policies

---------------------------------------------

PFB the details to implement access control in different elements-

1) Controller Commands

A.Using SQL Queries-

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

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='RegisteredUserCmdResourceGroup'), (select counter from keys where tablename='acrescgry'));

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

B. Using ACPLOAD utlility-

<Policies>

                <Action Name="ExecuteCommand"  CommandName="Execute"/>

                <ResourceCategory Name="com.ibm.commerce.sample.commands.MyControllerCmdResourceCategory"

                                ResourceBeanClass="com.ibm.commerce.sample.commands.MyControllerCmd">

                                <ResourceAction Name="ExecuteCommand"/>

                </ResourceCategory>    

                <ResourceGroup Name="AllSiteUserCmdResourceGroup"  OwnerID="RootOrganization">

                                <ResourceGroupResource Name="com.ibm.commerce.sample.commands.MyControllerCmdResourceCategory"/>

                </ResourceGroup>

</Policies>

2) Views

A.Using SQL Queries-

insert into acaction (acaction_id, action) values ((select counter from keys where tablename='acaction'), 'MyView');

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='MyView'));

update keys set counter=counter+1 where tablename ='acaction';

B. Using ACPLOAD utlility-

<Policies>

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

                <ActionGroup Name="AllSiteUsersViews" OwnerID="RootOrganization">

                                <ActionGroupAction Name="SpecialOrderView"/>

                </ActionGroup>

</Policies>

3) BOD command framework

Resources that the BOD commands act upon are nouns are represented by generated Java objects. These generated Java objects do not implement the Protectable interface required by the PolicyManager. 

To address this requirement, a wrapper object must be implemented for each noun to extract the information required by the PolicyManager to perform authorization checks. This mapping is defined in the wc-component.xml file

For SOI name-value pair commands, before they run, a command level and a resource level authorization is performed. 

In the BOD command framework, only resource level access control checks are performed, except for Get requests, where Get performs an access control check on whether the request is allowed to use the specified access profile.

There are two assets that need to be implemented for access control for a BOD command:

A. The Protectable Proxy class that represents the noun

B. Access control policies that grant user access to the particular command.

 

4) Enterprise Beans

Access control starts from the step when remote interface of the bean extends the com.ibm.commerce.security.Protectable interface at the time of creation

The enterprise bean class inherits default implementations for the following methods from com.ibm.commerce.base.objects.ECEntityBean:

      

fulfills()- The fulfills method must be implemented if there is an access control policy that includes this resource in its resource group, and also specifies a relationship or relationship group.

default returns false

getGroupingAttributeValue()- The getGroupingAttributeValue method must be implemented if there is an access control policy with an implicit resource group that includes certain instances of this resource, based on specific attribute values (for example, if there were an access control policy that pertains only pertains to Orders with status = 'P' (pending))

default returns null

getOwner()- Note that if the only relationship needed is "owner", then you do not need to override the fulfills method. In this case, the policy manager will make use of the result of the getOwner() method. 

default returns null

5) 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.

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

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

               

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

   

C. 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).

6) REST Services

A. For Create, Update, and Delete operations:

REST services must wrap BOD commands or controller commands to have access control enforced. This is the only supported and secure option.

B. For Get operations:

REST services must wrap BOD commands or data beans to have access control enforced.

REST over data beans: Access control is enforced if the underlying data bean implements the Delegator interface. If the data bean does not implement the Delegator interface, it can be called using local binding through JSP files, assuming the data bean does not expose sensitive data to the end user. If you are using remote binding through REST service calls, and the data bean does not implement the Delegator interface, only a Site Administrator can run the service call by default. This can be customized by overriding the isSiteResource(DataBean) method of the REST Resource Handler class.