---

Types of access control policies There are two types of access control policies: Standard policies Template policies Standard policies have a fixed owner. For example, if a standard policy is owned by Seller Organization, it will apply only to resources that are owned by Seller Organization and to resources that are owned by its descendant organizational entities, if they exist. The Root Organization is the ancestor organization of all other organizations in WebSphere Commerce, so any policy that is owned by Root Organization (member ID = -2001), by definition applies to all resources in the site. Thus, standard policies that are owned by the Root Organization are sometimes referred to as site-level policies. Standard policies that are not owned by Root Organization are referred to as organizational-level policies, because they do not apply site-wide but only to the resources that are owned by the policy owner or by any of its descendant organizational entities. Store administrators can manage the policies for their own organizational entity and its descendant organizational entities. Site administrators can modify all policies. Template policies have a dynamic owner. Template policies apply dynamically to the organizational entity that owns the resource and its ancestor organizational entities. For example, consider that there are 10 organizations under Root Organization, and that each one wants to ensure that Store Administrators can modify only resources that are owned by the Organization for which they play their role. There are two ways to set this up: Have one template policy that will dynamically apply to any of the 10 organizations, depending on the resource that is being accessed. The criteria for the access group in the template policy can also be dynamic. For example, if a user is trying to access a resource owned by Organization 3, the owner of the template policy will dynamically change to Organization 3, and the access group will also dynamically scope itself to Organization 3 (that is, the user must play the role of Store Administrator for Organization 3). Have 10 policies, each one owned by one of the 10 organizations. The access group for Organization 1 would specify that the user must play the Store Administrator role for Organization 1. The access group for Organization 2 would specify that the user must play the Store Administrator role for Organization 2, and so on. The advantage of the first solution is that there is only one physical copy of the policy, but 10 logical copies. Template policies can be managed by a site administrator. Overriding template policies: Another feature of template policies is that they can be overridden for specified organizational entities. Going back to the example above, if an eleventh organization entity is added to the WebSphere Commerce site, but this newest organizational entity does not want the above template policy to apply to it, there is a way to specify this: An entry must be added to the ACORGPOL table, specifying the policy ID of the template policy, and the organizational entity ID of the eleventh organization. This can also be done through the WebSphere Commerce Administration Console, when a Store Administrator deletes or updates a template policy in the context of a particular organization. When overriding a template policy for a descendant organization of Root Organization, the template policy will still apply at the Root Organization level. If the template policy is being overridden with a more restrictive policy at the descendant organization level, you should override the template policy at the Root Organization level as well. The only way to override a template policy for the Root Organization is through the database, by running the following SQL: insert into ACORGPOL (acpolicy_id, member_id) values ( (select acpolicy_id from ACPOLICY where policyname = `policyToOverride'), -2001) // Clear related topics

---

ibm.com/redbooks

+

Search Tips   |   Advanced Search