Secure > Authorization > Customize default access control policies

Define access control policy elements using XML

The Organization Administration Console allows you to make simple changes to access control policies and their parts.

To make more sophisticated changes, edit the XML files directly, and then load them into the database.

Before you begin making changes to the XML files for access control, you should read the topics Access Control and Create an access control policy. These topics provide a technical overview of access control and explains how to create customized commands, entity beans, and JSP templates that can be protected by access control policies.

Once you have finished the code customization, you can edit the XML files for access control to establish the protections you require.

The following changes can only be made by editing and then loading the appropriate XML files:

• Create or modifying an action

• Create or modifying a relationship

• Create or modifying a relationship group

• Create or modifying a resource

• Create or modifying attributes

• Create or modifying access groups using complex criteria

• Create or modifying resource groups using complex criteria

• Create a role-based policy for views

• Changing the action group in a role-based policy for views

• Create or modifying a policy group

• Associate policies with policy groups

You can manipulate the XML files to perform the following authorization tasks:

• Protect views

• Protect controller commands

• Protect resources

• Protect data beans

• Group resources by attributes

• Define relationships

• Define relationship groups

• Define access groups

• Define policies

• Access control files
  The following table provides the names and descriptions of the default WebSphere Commerce access control files (XML and DTD files). WebSphere Commerce loads these default files when you create the instance.

• Protect views
  Any view that is called directly from an URL, or that is launched as a redirect from another command, needs a role-based access control policy in order to be displayed.

• Protect controller commands
  All controller commands require a role-based access control policy in order to be executed. A controller or task command also requires a resource-level policy if the command is doing resource-level checking.

• Protect resources
  You can add resource-level access control to controller or task commands. Resource-level checking is done at WebSphere Commerce runtime, based on data returned by the getResources() method of a command. Resource-level checking can also be done during the performExcecute() portion of the command by making direct calls to the access control policy manager using the method void checkIsAllowed(Object resource, String action) throws ECException. This method will throw the ECApplicationException if the current user is not allowed to perform the specified action on the specified resource.

• Protect data beans
  Data beans contain information about business objects and are used to display object information about a Web page. Dynamic Web pages are usually mapped to views within WebSphere Commerce, and these views are protected by role-based policies. It is sometimes necessary to further protect the content of the Web page by protecting its data beans, if they exist.

• Group resources by attributes
  You may find that a resource policy that is based on class names needs to be more fine-grained than the default policies provided with WebSphere Commerce. An implicit resource group definition will provide the flexibility to protect resources of a particular state. For example, to create a policy in where all users can run the OrderRead command on orders that has status 'P' or 'E', then we will need to define a resource group as shown below.

• Define relationships
  A relationship provides the ability to grant a user access to a resource that is based on the user's relationship with the resource. If a relationship is defined in the policy, for a user to have access to the resource, the user must also satisfy the relationship with the resource in addition to satisfying the User Group, Action Group and Resource Group definitions. For example, an administrator may want to define a policy that only allows the creator of an order to update it. This type of policy definition is done through relationships.

• Define relationship groups
  If multiple relationships are required to grant a user access to certain resource, you can make use of the relationship group construct. However a relationship usually satisfies most of the requirement for this scenario. Relationship groups contain open conditions which are the conditions for belonging to the relationship group. If define relationship groups, do so by defining the relationship group information in the XML file, or by modifying the defaultAccessControlPolicies.xml file.

• Define access groups
  An access group is a required element in a policy definition. It defines which users are entitled to act upon which resources. There are many instances where it is necessary to define a new access group.

• Define policies
  There are many instances where it is necessary to define a new access group.

+

Search Tips   |   Advanced Search