Debugging access control in WebSphere Commerce

Mike Callaghan May 14, 2008

Sidy Doumbia

This article discusses two methods for debugging access control in WebSphere® Commerce:
trace searching and direct database querying.

Introduction
Exercising proper access control is critical for securing the WebSphere Commerce environment.
The complexity of the implemented access control grows as new commands and views are added
or removed. With each addition or removal, it is easy to break existing policies or see the newly
added policy behave differently from expected. This article discusses methods for debugging
access control.

Problem determination usually starts with an access control error in the storefront. To better
identify the problem, two methods are available: trace searching and direct database querying.
When the problem is identified, you can fix it by using two methods: using loading xml files or
direct SQL inserts to the database. Both of these methods are covered in this article.

Note: This article focuses on debugging access control. It assumes the reader has some
knowledge of access control in WebSphere Commerce.

Legitimate access control failure versus real access control failure

The best way to recognize an access control failure is by a statement, such as this one in
SystemOut.log:
[1/01/08 13:44:27:141 CDT] 6a36e74e CommerceSrvr E AccManager isAllowed CMN1501E:
User 408002 does not have the authority to perform action "MyNewView" on resource
"com.yourcompany.command.MyHttpForwardViewCommandlmpl"

You may also experience an access control failure directly from the store front with the following
error message: ERR_USER_AUTHORITY.

After confirming an access control problem, determine if the failure is a legitimate one or if you
need to fix it. A legitimate failure is access control doing what it was designed to do; for example,

© Copyright IBM Corporation 2008 Trademarks

Debugging access control in WebSphere Commerce Page 1 of 16
developerWorks® ibm.com/developerWorks/

preventing a specific registered user from accessing another registered user's order or account
information. An example of an access control issue is when a newly written command fails to
execute because of a user authority error, as seen in the previous log snippet.

Troubleshooting techniques
There are two ways to debug access control failures:

• Read through the trace, check policy-by-policy why they are not applying, and co-relate to the
XML loaded in.
• database directly to see what is missing, based on the criteria being checked.

Read the trace

The message shown from the SystemOut.log above, although it reports an access control failure,
provides little in the way of debugging which policies are checked and why each fails. To provide
more help in debugging an access control failure, turn on the access control component tracing
with the following string:
com.ibm.websphere.commerce.WC_ACCESSCONTROL=all

For more information about turning on tracing, see Configuring logging in the WebSphere
Commerce Information Center. You can analyze it after the trace is enabled, after the scenario is
reproduced, and trace.log is gathered. Starting from the end of the file, perform a backward search
for "=false" to find the access control check that failed. For example:
[1/01/08 13:44:27:141 CDT] 6a36e74e WC_ACCESSCONT d
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl isAllowed PASSED? =false
[1/01/08 13:44:27:141 CDT] 6a36e74e WC_ACCESSCONT <
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl isAllowed Exit
[1/01/08 13:44:27:141 CDT] 6a36e74e CommerceSrvr E AccManager isAllowed CMN1501E:
User 40501 does not have the authority to perform action "MyNewView" on resource
"com.ibm.commerce.command.HttpForwardViewCommandlmpl"

To determine what action was being checked which led to this failure, perform another backward
search for the string "isAllowed?". Ensure that it is for the same thread ID:
WC_ACCESSCONT ... PolicyManagerImpl.isAllowed
isAllowed? User=40501; Action=MyNewView; Resource=
com.ibm.commerce.command.HttpForwardViewCommandlmpl; Owner=7000000020002000000;
Resource Ancestor Orgs=7000000020002000000,7000000020000000000,-2001;
Resource Applicable Orgs=7000000020002000000

In between the "isAllowed?" and "PASSED? =false" statements, the PolicyManager iterates
through the access control policies one by one to determine if any apply to the above criteria. For
WebSphere Commerce V6.0, any policy where the action is in the ActionGroup and the resource is
in the ResourceGroup will be identified and evaluated in the trace, similar to the following:

Debugging access control in WebSphere Commerce Page 2 of 16

ibm.com/developerWorks/ developerWorks®

WC_ACCESSCONT d
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl isAllowed Found
PolicyName: BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup;
PolicyType: 2; PolicyOwner: -2001
WC_ACCESSCONT >
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl
getPolicyApplicableOrgs Entry
WC_ACCESSCONT d
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl getPolicyApplicableOrgs
Policy Applicable Orgs=-2000
WC_ACCESSCONT <
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl getPolicyApplicableOrgs
Exit
WC_ACCESSCONT d
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl evaluatePolicy
Evaluating PolicyName: BecomeUserCustomerServiceGroupExecutesBecomeUserCmdsResourceGroup

When the "Evaluating PolicyName" statement is made, the PolicyManager checks for each of the
following criteria, based on the elements in the isAllowed statement:

1. The Action is in the ActionGroup.

2. The Resource is in the ResourceGroup.
3. The User is in the UserGroup.
4. The relation between the User and the Resource holds.
5. A policy that matches the above is subscribed to by the organization.

Figure 1 describes how these four pieces fit together and shows a typical access control scenario.

Figure 1. Sample organization tree with access control

We will take a deeper look at each of these criteria and what happens if they are not upheld.

Debugging access control in WebSphere Commerce Page 3 of 16

developerWorks® ibm.com/developerWorks/

Query the access control database tables

Other than reading through each policy identified in the trace, you can also query the relevant
database tables to check if each part of a policy is holding up for the criteria being checked. We
will show how to check for each part.

Action is in the ActionGroup

If a new view is created and no access control is loaded, then when you invoke the view, you get
an access control error. In the trace.log file only, the SiteAdminCanDoEverything policy is logged,
but the user is not a Site Administrator. The following logs show the access control failure.
PolicyManagerlmpl.isAllowed isAllowed? User=123;
Action=MyNewView;Resource=com.ibm.commerce.command.HttpForwardViewCommandlmpl;
owner=-2001; Resource Ancestor Orgs=-2001,-2001; Resource Applicable Orgs=-2001

PolicyManagerlmpl.isAllowed Found PolicyName: SiteAdministractorsCanDoEverything;

PolicyType: 2; PolicyOwner:-2001
PolicyManagerlmpl.getPolicyApplicableOrgs Policy Applicable Orgs=-2001

PolicyManagerlmpl.evaluatePolicy Evaluating PolicyName SiteAdministratorsCanDoEverything

WC_ACCESSCONT d PolicyManagerlmpl.isAllowed PASSED?=false

Because the trace shows only SiteAdministratorsCanDoEverything and no other policies and you
made a new view, define it as an action and include it in an ActionGroup tied to a policy.

As a sample solution, use the out-of-the-box policy for all views,

AllUsersExecuteAllSiteUsersViews:
<Policy Name="AllUsersExecuteAllSiteUsersViews"
OwnerID="RootOrganization"
UserGroup="AllUsers"
ActionGroupName="AllSiteUsersViews"
ResourceGroupName="ViewCommandResourceGroup"
PolicyType="groupableStandard">
</Policy>

Here, the ActionGroup is AllSiteUsersViews. For a new view, define it to be a part of the
AllSiteUsersViews ActionGroup. Define the view as an action and then use ActionGroupAction to
tie into the ActionGroup:
<Action Name="MyNewView"
CommandName="MyNewView">
</Action>

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

<ActionGroupAction Name="MyNewView"/>
</ActionGroup>

Alternatively, you can also define a new ActionGroup and tie the new action into this one. If doing
this, ensure that you also define a policy to use this ActionGroup. Otherwise, it will have no effect
during runtime.

Debugging access control in WebSphere Commerce Page 4 of 16

ibm.com/developerWorks/ developerWorks®

Query the database

You can also query the database to find if all the pieces are there for the particular action. In the
example above, check first if the action is defined. Remember to replace the "MyNewView" with
what appears as the action in the isAllowed statement:
select ACACTION_ID from ACACTION where ACTION = 'MyNewView'

Note: In the above query and all subsequent ones in this article, you must update the action and
the resource to match those in your "isallowed?" statement. If the action is in place, make sure it is
tied into an ActionGroup:
select acactgrp_id from acactactgp where acaction_id in (select ACACTION_ID from ACACTION
where ACTION = 'MyNewView')

If the action is in an ActionGroup, check if a policy is using this ActionGroup:

select distinct acpolicy_id from acpolicy where acactgrp_id in (select acactgrp_id
from acactactgp where acaction_id
in (select ACACTION_ID from ACACTION where ACTION = 'MyNewView'))

Figure 2 portrays how the entries are arranged in the database, from the ACPOLICY table all the
way down to the ACACTION table.

Figure 2. Policy to Action relationship chain

Resource is in the ResourceGroup (command-level failure)

If a new controller command is created and no access control is loaded, then when
invoking the command, you will get an access control error. In the trace.log file only the
SiteAdminCanDoEverything policy is logged, but the user is not a Site Administrator. The following
logs show the access control failure.

Debugging access control in WebSphere Commerce Page 5 of 16

developerWorks® ibm.com/developerWorks/

PolicyManagerImpl.isAllowed isAllowed? User=6789; Action=Execute;

Resource=com.yourcompany.MyOrderItemAddCmdImpl; Owner=-2001;
Resource Ancestor Orgs=-2001,-2001; Resource Applicable Orgs=-2001 ...

PolicyManagerlmpl.isAllowed Found PolicyName: SiteAdministractorsCanDoEverything;

PolicyType: 2; PolicyOwner:-2001
PolicyManagerlmpl.getPolicyApplicableOrgs Policy Applicable Orgs=-2001

PolicyManagerlmpl.evaluatePolicy Evaluating PolicyName SiteAdministratorsCanDoEverything

WC_ACCESSCONT d PolicyManagerlmpl.isAllowed PASSED?=false

You can recognize a command-level failure when Execute is the action and the resource is the
command.

The trace shows only the SiteAdministratorsCanDoEverything policy. Since you made a new
command, you need to define it as a resource and include it in a ResourceGroup tied to a policy.

As a sample solution, you can make a new policy for all commands similar to the out-of-the-box
one, but with a different resource group:
<Policy Name="AllUsersExecuteCmdResourceGroup"
OwnerID="RootOrganization"
UserGroup="AllUsers"
ActionGroupName="ExecuteGroup"
ResourceGroupName="MyResourceGroup"
PolicyType="groupableStandard">
</Policy>

Here the ResourceGroup is MyResourceGroup. For a new command, define it to be a part of the
MyResourceGroup ResourceGroup. Define the command as a ResourceCategory, and then use
ResourceGroupResource to tie into the ResourceGroup:
<ResourceCategory Name="com.yourcompany.MyOrderItemAddCmdCategory"
ResourceBeanClass=" com.yourcompany.MyOrderItemAddCmd">
<ResourceAction Name="ExecuteCommand"/>
</ResourceCategory>

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

<ResourceGroupResource Name=" com.yourcompany.MyOrderItemAddCmdCategory "/>
</ResourceGroup>

Note that you also want to allow the "Execute" action for the command, as denoted by the
ResourceAction above.

Alternatively, you can tie the command into an existing ResourceGroup.

Query the database

You can also query the database to find if all the pieces are there for the particular action. In the
example above, check if the Action is defined. Remember to replace MyOrderItemAddCmd with
whatever appears as the action in the isAllowed statement:
select distinct acrescgry_id from acrescgry
where resclassname = 'com.yourcompany.MyOrderItemAddCmd'

Debugging access control in WebSphere Commerce Page 6 of 16

ibm.com/developerWorks/ developerWorks®

If the action is in place, also make sure it is tied into an ActionGroup:

select distinct acresgrp_id from acresgpres where acrescgry_id in
(select distinct acrescgry_id from acrescgry
where resclassname = 'com.yourcompany.MyOrderItemAddCmd')

If the resource is in a ResourceGroup, check if a policy is using this ResourceGroup:

select acpolicy_id,policyname from acpolicy where acresgrp_id in
(select acresgrp_id from acresgpres where acrescgry_id in
(select acrescgry_id from acrescgry
where resclassname = 'com.yourcompany.MyOrderItemAddCmd'))

Figure 3 shows the new resource along with its connection to the ResourceGroup, all the way up
to the policy.

Figure 3. Policy to resource relationship chain

Action cannot invoke resource (resource-level failure)

When the command-level check above has passed and the resource implements the
getResources() method, this second check is done as well. You can recognize a resource-level
failure when the controller command is the action and the resource is a bean.
PolicyManagerlmpl.isAllowed isAllowed isAllowed? User=40501; Action=com.yourcompany.
command.MyControllerCmd;
Resource=com.ibm.commerce.user.objects._User_Stub; Owner=534519;
Resource Ancestor Orgs=-2000,-2001; Resource Applicable Orgs=-2000; resource is Groupable

Again, the trace shows only the SiteAdministratorsCanDoEverything and no other policies. That is
because you have not defined a resource-level policy tying the command to this bean.

As a sample solution, add the bean as a resource in the resource group used for the command,
the policy attachments stay the same:

Debugging access control in WebSphere Commerce Page 7 of 16

developerWorks® ibm.com/developerWorks/

<ResourceCategory Name="com.ibm.commerce.user.objects.UserResourceCategory"
ResourceBeanClass="com.ibm.commerce.user.objects.User">
<ResourceAction Name="com.yourcompany.MyOrderItemAddCmd"/>
</ResourceCategory>

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

<ResourceGroupResource Name="com.ibm.commerce.user.objects.UserResourceCategory"/>
</ResourceGroup>

Single policy matches both ActionGroup and ResourceGroup

Remember, if the access control policy you are expecting to work does not appear in the trace, this
means that either the action is not in the ActionGroup, or the resource is not in the ResourceGroup
of the policy.

If the action and resource are both defined correctly based on the above, make sure that the single
access control policy is defined for both combinations. You can merge the two queries to check
this:
select distinct acpolicy_id from acpolicy where acactgrp_id in
(select acactgrp_id from acactactgp where acaction_id in
(select ACACTION_ID from ACACTION where ACTION = 'MyNewView')) and acresgrp_id in
(select acresgrp_id from acresgpres where acrescgry_id in
(select acrescgry_id from acrescgry
where resclassname = 'com.yourcompany.command.MyHttpForwardViewCommandlmpl'))

If this query does not return a result, then either the action or resource needs to be pulled into the
corresponding group accordingly.

User is in the UserGroup

A UserGroup is the part of the access control policy that refers to member groups in the database
from the MBRGRP table. For the sake of simplicity, we refer to both as the same in this article.
A UserGroup failure will throw a message similar to the following:
[3/7/08 11:31:18:374 EST] 0000005d WC_ACCESSCONT <
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl
checkUserInCmdLevelUserGroup Exit
false
[3/7/08 11:31:18:374 EST] 0000005d WC_ACCESSCONT 3
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl evaluatePolicy
Command Level UserGroup does not match

Note that the message "Command Level UserGroup does not match" may be different, depending
on which UserGroup is failing and where it is failing (command level check or resource level
check). Similar messages you may see are:

• Template UserGroup does not match

• Normal UserGroup does not match
In most cases, access control will use implicit UserGroups that are validated using conditions in
the database. The current user will be validated against the condition that is in the MemberGroup

Debugging access control in WebSphere Commerce Page 8 of 16

ibm.com/developerWorks/ developerWorks®

Condition table using the user's role. The following code snippet shows how the out-of-the-box
"RegisteredCustomers" UserGroup is defined.
<UserGroup Name="RegisteredCustomers"
OwnerID="RootOrganization"
Description="Users with Registered Customer role"
MemberGroupID="-197">
<UserCondition> <!
[CDATA[
<profile>
<orListCondition>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Registered Customer"/>
</simpleCondition>
</orListCondition>
</profile>
]]>
</UserCondition></UserGroup>

The above will evaluate at runtime to check that the user invoking the action plays the role of
"Registered customer". Here, you are not checking which organization that the role is played in, it
just needs to be in any organization. This is referred to as a Normal UserGroup.

Alternatively, you can also define the UserGroup for the policy to require the role to be played in a
specific organization.
<profile>
<simpleCondition>
<variable name="role"/>
<operator name="="/>
<value data="Registered Customer"/>
<qualifier name="org" data="OrgAndAncestorOrgs"/>
</simpleCondition>
</profile>

The qualifier of OrgAndAncestorOrgs checks if the user has the specified role in the organization
that owns the resource or any of its ancestor organizations. This defines a Template UserGroup.
Whereas the Normal UserGroup was RegisteredCustomers, all Template UserGroups follow the
naming convention of appending "ForOrg" to the name, such as RegisteredCustomersForOrg.

Note that the Normal and Template UserGroups are what determine whether your
access control policy is a Standard (type 2) or Template Policy (type 3), as defined in the
ACPOLICY.POLICYTYPE field.

Figure 4 depicts a diagram with the UserGroup along with its condition in the MBRGRPCOND
table.

Debugging access control in WebSphere Commerce Page 9 of 16

developerWorks® ibm.com/developerWorks/

Figure 4. Policy to implicit user group relationship

One special UserGroup is the AllUsers group, which uses <trueCondition>, meaning it always
evaluate to true implicitly, including any and all users.

Along with implicit MemberGroups, there are explicit ones as well. That means the affiliation to a
group is done explicitly by associating the MBRGRP_ID and MEMBER_ID of the user in question
in the MBRGRPMBR (Member Group Member) table. If a MemberGroup is used, Figure 5 shows
what the database content will look like.

Figure 5. Policy to explicit user group relationship

The UserGroup allows the policy to scope which users have access to it. Let's look at a previously
discussed policy and see how you can adapt it to only pertain to registered customers:
<Policy Name="AllUsersExecuteCmdResourceGroup"
OwnerID="RootOrganization"
UserGroup="RegisteredCustomers"
ActionGroupName="ExecuteGroup"
ResourceGroupName="MyResourceGroup"
PolicyType="groupableStandard">
</Policy>

Query the database

When troubleshooting UserGroups (also known as MemberGroups), note the following tables:

• ACPOLICY

Debugging access control in WebSphere Commerce Page 10 of 16

ibm.com/developerWorks/ developerWorks®

• MBRGROUP
• MBRGRPCOND
• MBRROLE
• MGRGRPMBR (if using explicit MemberGroups)

The following queries illustrate which data to get from which table.

Start by getting the MBRGRP_ID from ACPOLICY:

Select MBRGROUP_ID from ACPOLICY where Policyname = 'AllUsersExecuteCmdResourceGroup'"

For implicit groups, you need two steps to validate that the user is in this group:

1. Validate the condition of the MemberGroup:

Select CONDITIONS from MBRGRPCOND where MBRGRP_ID=(Select
MBRGROUP_ID
from ACPOLICY where Policyname =
'AllUsersExecuteCmdResourceGroup'")

This query yields a snippet similar to the one above containing:

<variable name="role"/>
<operator name="="/>
<value data="Registered Customer"/>
2. When the condition is verified, check the role of this user in the MBRROLE table. Assuming
the MEMBER_ID of the current user is 2002, for example, you can run the following query:
select DISPLAYNAME from ROLEDESC
where ROLE_ID=(select ROLE_ID from MBRROLE where MEMBER_ID=2002)

If this query shows a different role than "Registered Customer", then you can set this
customer up to have a registered customer role through the OrgAdminConsole (preferred
method), or make an SQL INSERT in the MBRROLE table to make this user play the
Registered Customer role in a needed organization (for example, the B2C organization).

For explicit UserGroups, run different queries. The initial step to get the MBRGRP_ID from the
ACPOLICY table is the same. Next, run a query to find out if the MEMBER_ID of this user is
associated with the MemberGroup you want to use in the Policy, for example, MyMbrGroup as
seen in Figure 5.
Select MBRGRP_ID,MEMBER_ID from MBRGRPMBR where MEMBER_ID=2002
AND MBRGRP_ID =(Select MBRGROUP_ID from ACPOLICY
where Policyname = 'AllUsersExecuteCmdResourceGroup'")

In the above query, you may replace the part that fetches MBRGRP_ID directly if you know
your MBRGRP_ID. If this query comes back empty, then the user is not in the MemberGroup.
Therefore, you must make an SQL insert in the MBRGRPMBR table to associate user 2002 with
the needed MemberGroup.

Debugging access control in WebSphere Commerce Page 11 of 16

developerWorks® ibm.com/developerWorks/

User has the correct relation to the resource

The relation is an optional criterion that may or may not be added to the three groups listed earlier
for additional security. Let's use the following policy as an example:
<Policy Name="AllUsersDisplayOrderDatabeanResourceGroup"
OwnerID="RootOrganization"
UserGroup="AllUsers"
ActionGroupName="DisplayDatabeanActionGroup"
ResourceGroupName="OrderDatabeanResourceGroup"
RelationName="creator"
PolicyType="groupableStandard">
</Policy>

In addition to providing the usual checks for UserGroup, ActionGroup and ResourceGroup, this
policy adds an extra check for the Relation. Having the relation allows this policy to be validated
only if the user checked is the actual creator of the resource checked (for example, an Order
bean). This is validated at runtime. For example, a user currently shopping on the storefront is the
creator of the shopping cart containing his items. If other users try to do operations on the previous
user's cart, this policy stops them.

To troubleshoot this kind of policy, make sure all the three groups seen in the previous sections
of this article are valid. Next, you need to be familiar with the beans and database tables in
WebSphere Commerce. You must locate the table pertaining to the bean and check to see if the
user checked during access control is indeed the creator of the resource in question. You can
locate this type of resource level failure in the logs as shown in the snippet below:
WC_ACCESSCONT 3
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl isExecutionAllowed
isAllowed? User=18135; Action=Display;
Resource=com.My.commerce.order.beans.OrderListDataBean; Owner=7000000000000000151;
Resource Ancestor
Orgs=7000000000000000151,7000000000000000004,7000000000000000003,
7000000000000000001,-2001; Resource Applicable Orgs=7000000000000000151
WC_ACCESSCONT 3
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl isExecutionAllowed
Found PolicyName: AllUsersDisplayOrderDatabeanResourceGroup;
PolicyType: 2; PolicyOwner: -2001
...
WC_ACCESSCONT 3
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl evaluatePolicy
Relationship check: creator -> false
WC_ACCESSCONT 3
com.ibm.commerce.accesscontrol.policymanager.PolicyManagerImpl
isExecutionAllowed PASSED? =false

As mentioned previously, identify the table mapping to the bean being checked. For example,
when dealing with Order beans, do the following:

1. Note the userID being checked in the policy, in this case, User 18135.
2. Search the trace to find out which orderId is currently being worked on. For that, you will most
likely need WC_ORDER tracing.
This step depends on the type of resource in use. You may or may not need to turn on
additional tracing. For instance, if the resource being retrieved is a user bean (data from the

Debugging access control in WebSphere Commerce Page 12 of 16

ibm.com/developerWorks/ developerWorks®

USERS table), there is no need to turn on additional tracing as the userID is in the isallowed?
part of the trace.
3. Last, check the Orders table and look for the MEMBER_ID associated with the order (note
that we use the MEMBER_ID as in the USERS table and not ORGENTITY_ID, which is also
available in the Orders table).
When you have those two IDs, compare them to see if the MEMBER_ID in the isallowed?
portion of the trace is the same as the one in the ORDERS table. If not, then you have a valid
case of access control where another user tried to access someone else's shopping cart.
Query the database
The following query helps with the steps provided above:
Select * from ORDERS where ORDERS_ID=<identified OrderID> AND MEMBER_ID=18135

Organization subscribes to policy group containing the valid policy

If all of the criteria you looked at so far hold true, you have a valid policy. However, for this policy to
be used during runtime, it must belong to a policy group. You must subscribe this policy group by
the organization owning the resource.

Take the following failure example, caused by insufficient policy subscriptions:

PolicyManagerImpl.isAllowed isAllowed? User=6789; Action=Execute;
Protectable=com.ibm.commerce.catalog.commands.ProductDisplayCmdImpl; Owner=2002;
Resource Ancestor Orgs=2002,-2001; Resource Applicable Orgs=2002
PolicyManagerImpl.isAllowed Found PolicyName:
AllUsersExecuteResellerUserCmdResourceGroup; PolicyType: 3; PolicyOwner: -2001
PolicyManagerImpl.getPolicyApplicableOrgs
No organizations subscribe to a policy group with this policy
PolicyManagerImpl.isAllowed Policy does not apply
to the resource's applicable organizations ...
PolicyManagerImpl.isAllowed PASSED? =false

Here, the policy meets all other criteria, but no organization is subscribing to a policy group
containing this policy. If the only policy that is applicable in our policy manager evaluation is the
AllUsersExecuteResellerUserCmdResourceGroup, then there are two things you need to ensure
for this check to pass:

• This policy has to be in a policy group. A policy alone is of no use because all subscriptions
are to a policy group, not a single policy.
• The policy group is subscribed to by the correct organization.
Ensure that the resource owner is subscribing to the correct policy groups. For example:
<Policies>
<PolicyGroup Name="SomeKnownPolicyGroup" OwnerID="RootOrganization">
<PolicyGroupPolicy Name=
"AllUsersExecuteResellerUserCmdResourceGroup"
PolicyOwnerId="RootOrganization" />
<PolicyGroupSubscription OrganizationID="RootOrganization"/>
</PolicyGroup>
</Policies>

Debugging access control in WebSphere Commerce Page 13 of 16

developerWorks® ibm.com/developerWorks/

Query the database

Query the ACPLGPSUBS database table to determine whether there is a correct association
between the necessary access control policy groups and the organizational entities. For example,
ensure that the current store's organization is associated with B2CPolicyGroup:
select orgentity_id, acpolgrp_id from acplgpsubs where acpolgrp_id in
(select distinct acpolgrp_id from acpolgppol where acpolicy_id in
(select distinct acpolicy_id from acpolicy where acactgrp_id in
(select acactgrp_id from acactactgp where acaction_id in
(select ACACTION_ID from ACACTION where ACTION = 'Display')) and acresgrp_id in
(select acresgrp_id from acresgpres where acrescgry_id in (select acrescgry_id
from acrescgry where resclassname = 'com.ibm.commerce.user.objects.User'))))

You get the following result:

orgentity_id acpolgrp_id

2002 10001

2002 10003

Subscribe the organization to the policy group. In this example, the organization subscribes to
policy group 10001. You can do this through the OrgAdminConsole or a direct SQL INSERT in the
ACPLGPSUBS table.

If you have a policy subscription problem, look at the resource references from the trace, for
example:
Resource Ancestor Orgs=2002,-2001; Resource Applicable Orgs=2002

When checking policy group subscriptions, this checks for the subscriptions from the first
organization listed, such as 2002. If it subscribes to a group containing the relevant policy, this will
pass. If it does subscribe to policy groups, but none contain the relevant policy, access control will
fail. If it does not subscribe to any policies of its own, then only in this case it will check its closest
ancestor, such as -2001. The subscriptions of this organization are inherited and applicable for the
organization, only because you do not subscribe to any of the policy groups.

Conclusion
This article described how to troubleshoot and fix an access control policy failure from all angles
of a policy. Remember that access control enables security on your site and you do not have to
fix every access control "failure". Take the example where the failure reports that a user cannot
display the account information of another user. This clearly is access control reporting that has
worked. In cases where you need to fix access control failures, the "divide and conquer" attitude
works well for the access control policy. Locate all four components (MemberGroup, AccessGroup,
Relation, and ResourceGroup) and make sure each one is properly loaded in the database.

Debugging access control in WebSphere Commerce Page 14 of 16

ibm.com/developerWorks/ developerWorks®

Acknowledgements
The authors would like to thank Ibrahim Boubacar Doumbia and Assa H. Cisse for their help in
preparing and reviewing the article.

Debugging access control in WebSphere Commerce Page 15 of 16

developerWorks® ibm.com/developerWorks/

Related topics
• Webcast replay: Access Control WebSphere Support Technical Exchange
• WebSphere Commerce Information Center: Troubleshooting access control problems
• WebSphere Commerce Information Center: Implementing access control
• WebSphere Commerce Infomation Center: Access control data model
• WebSphere Commerce Information Center: Member data model

© Copyright IBM Corporation 2008

(www.ibm.com/legal/copytrade.shtml)
Trademarks
(www.ibm.com/developerworks/ibm/trademarks/)

Debugging access control in WebSphere Commerce Page 16 of 16