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.
