|
|
Access control policy conceptsAccess control policies grant users access to the site. Unless they are authorized to perform their responsibilities through one or more access control policies, users have no access to any of the site's functions. Each access control policy takes the following form:
AccessControlPolicy [AccessGroup,ActionGroup,ResourceGroup,Relationship]
The elements in the access control policy specify that a user belonging to a specific access group is permitted to perform actions in the specified action group on resources belonging to the specified resource group, as long as the user satisfies a particular relationship with respect to the resource. The relationship is specified only when needed. For example, [AllUsers,UpdateDoc,doc,creator] specifies that all users can update a document if they are the creator of the document. The following sections describe conceptual information and terminology associated with access control. Member groupsThe Member subsystem in WebSphere Commerce enables you to create member groups, which are groups of users categorized for various business reasons. The groupings can be used for many purposes, such as access control purposes, approval purposes, and marketing purposes such as calculating discounts and prices, and displaying products. A member group of type Access Group (-2) is for access control purposes, while a member group of type User Group (-1) is for general use. A member group is associated with member group types in the MBRGRPUSG table. Access groups: A member group of type Access Group (-2) is for grouping users for access control purposes. An access group, one element of an access control policy. is a group of users defined specifically for access control purposes. The criteria for membership in an access group is usually based on roles, the organization to which the user belongs, or the user's registration status. For example, the access group called Buyer Administrators is a group whose users each play the role of Buyer Administrator. WebSphere Commerce includes several default roles, and corresponding to each role is a default access group that implicitly references that role. Roles can be used as attributes to add users to an access group based on the type of activities they perform in the site. For example, by default there is a role called Seller Administrator and a corresponding access group called Seller Administrators. A Site Administrator uses the WebSphere Commerce Administration Console to create, maintain, and delete access groups for a site. A Buyer Administrator or a Seller Administrator uses the WebSphere Commerce Organization Administration Console to assign roles to users or to explicitly assign users to access groups. Access groups can be implicit, explicit, or both. An implicit access group is defined by a set of criteria. Anyone who satisfies the criteria is a member of the group. The criteria are usually based on a user's roles, parent organization, or registration status. The implicit conditions that define membership in a member group are in the CONDITIONS column of the MBRGRP table. Using implicit access groups that specify the attributes of users makes it easy to authorize access to similar users without having to explicitly assign and unassign individual users. It also eliminates the need to update the members of a group when a user's attributes change. A simple criterion for an access group is to include everyone who has been assigned a specific role, regardless for which organization the user plays the role. A more complex criterion would be to specify that only users that play one of a possible set of roles for a particular organization would belong to the access group. It is possible to explicitly add or remove a user from a member group. Both of these explicit specifications can be done using the MBRGRPMBR table. An explicit access group contains explicitly assigned users who may or may not share common attributes. This also enables you to exclude individuals whom to exclude from an implicitly defined group, even though they satisfy the conditions for inclusion. User groups: A member group of type User Group (-1) is a collection of users, defined by the merchant, who share a common interest. User groups are similar to clubs that are offered by large stores for their frequent or preferred customers. Being part of a user group can entitle customers to discounts or other bonuses for purchasing products. For example, if market research shows that senior customers repeatedly purchase travel books and luggage, you can assign these customers to a member group called Seniors' Travel Club. Likewise, you can create a user group to reward frequent customers for their business. ActionsGenerally, an action is an operation that is performed on a resource. In role-based policies for controller commands, the action is Execute and the resource is the command being executed. In role-based policies for Views, the action is the name of the view; com.ibm.commerce.commands.ViewCommand is the resource. For resource-level access control, actions typically map to WebSphere Commerce commands, and the resource is usually the remote interface of a protected EJB™ (Enterprise JavaBean). For example, the controller command com.ibm.commerce.order.commands.OrderCancelCmd operates on the com.ibm.commerce.order.objects.Order resource. The Display action is used to activate data bean resources. The WebSphere Commerce Administration Console can be used by a Site Administrator to associate existing actions with action groups but not for creating new actions. New actions can be created by defining them in an XML file and then loading them to the database. Actions are stored in the ACACTION table. Action groupsAction groups are groups of related actions. An example of an action group is the AccountManage group that includes the following commands:
Only the Site Administrator can create, update, and delete action groups. This can be done from the WebSphere Commerce Administration Console and through XML. Action groups are stored in the ACACTGRP table. Actions are associated with action groups in the ACACTACTGP table. Resource categoryResource category refers to a class of resources that need to be protected by access control. Resources must implement the Protectable interface information. Resource categories are Java classes such as order, RFQ, and auction. Resources are the instances of these classes. For example, Auction1 created by Auction Administrator A is one resource; Auction2 created by Auction Administrator B is another resource. These two resources belong to the resource category: auction. Resource categories are defined in the ACRESCGRY table and for convenience are sometimes referred to as resources. A Site Administrator can associate existing resource categories with resource groups using the WebSphere Commerce Administration Console. New resource categories can be created using XML. ResourcesResources are any objects in the system that need to be protected. For example, RFQs, auctions, users, and orders are some of the resources in WebSphere Commerce that need to be protected. Each resource has an owner. The ownership of the resource is used to determine which access control policies apply to it. Access control policies have an owner, which is an organizational entity. A policy is applied only to resources that are owned by the same organizational entity that owns the policy. Policies that are owned by ancestor organizational entities are also applied to the resource. Controller command resources: For role-based access control for controller commands, the policy is structured such that the Execute action is being performed on the controller command resource. These policies are intended to restrict the execution of controller commands to users with a specified role. The access group for these policies is usually those with a single role, such as Product Managers (those with the Product Manager role). The resource group would be the set of controller commands that a product manager can execute. While enforcing role-based access control on a controller command, the owner of the command must be determined. This is done by calling the getOwner() method on the command if it has been implemented. Usually this method is not implemented, so WebSphere Commerce Runtime will evaluate it by doing one of the following:
Data bean resources: Not all data beans require protection. Within the existing WebSphere Commerce application, data beans that require protection already implement the required access control. The question of what to protect comes into play when you create new data beans. Deciding which resources to protect depends on the application. A data bean should be protected (directly or indirectly) if the information to be displayed is not sufficiently protected by the role-based access control on the view that corresponds to the JSP that contains the data bean. If a data bean should be protected and can exist on its own, it should be directly protected. If the existence of a data bean depends on the existence of another data bean, then it should delegate to the other data bean for protection. An example of a data bean that would be directly protected is the Order data bean. An example of a data bean that would be indirectly protected is the OrderItem data bean, as it cannot exist without an data bean. Refer to the WebSphere Commerce Programmer's Guide for more information about how to protect the data bean resource. Data resources: Data resources refer to business objects that can be manipulated, such as auctions, orders, RFQs, and users. These are usually protected at the enterprise bean level, but it is possible to protect any class that implements the Protectable interface. Data resources are protected using resource-level access control checks. The common way to do this is by returning data resources in the getResources() method of a controller or task command. For more information, see the WebSphere Commerce Programmer's Guide. Resource groupsA resource group identifies a set of related resources. A resource group can include business objects such as a contract or a set of related commands. In access control, resource groups specify the resources to which the access control policy authorizes access. Resource groups are defined in the ACRESGRP table. Site Administrators can manage resource groups and associate resources with resource groups using the WebSphere Commerce Administration Console, or by using XML. Implicit resource groups: Implicit resource groups define resources that match a certain set of attributes. One of these attributes must be the Java class name. Other attributes may include status, store ID, price, and so on. For example, you could create an implicit resource group that includes all orders that have pending status (ORDERS.STATUS=P). Implicit resource groups are usually used for grouping resources that will be used in resource-level policies when the resources share a common attribute beyond the Java class name. Implicit resource groups are defined using the CONDITIONS column of the ACRESGRP table. Simple implicit resource groups can be created using the WebSphere Commerce Administration Console. Increasingly complex groups can be created using XML. Explicit resource groups: Explicit resource groups are specified by associating one or more resource categories to a resource group. This association is done in the ACRESGPRES table. Adding a resource category to a group explicitly, by listing its Java class name, enables you to group individual resources that might not necessarily share common attributes. RelationshipsEach resource may have some kind of relationship associated with it, and a set of members that fulfill each relationship. For example, all resources have a relationship of owner, which is fulfilled by the owner of the resource. Other relationships can include recipients of documents and the creator of an order. These resource relationships are important in determining who can perform certain actions on a particular instance of a resource. For example, the creator of a document may not be able to delete it, but perhaps an auditor may. Similarly, a reviewer may only be able to read and approve a document, but not forward it or perform other operations. Relationships are stored in the ACRELATION table, and, optionally, are specified in an access control policy using the ACRELATION_ID column of the ACPOLICY table. When evaluating a policy that requires the fulfillment of a relationship between the user and the resource, the fulfills(Long Member, String relationship) method on the resource will be called to evaluate it. When compared to relationship groups, these relationships are sometimes referred to as simple relationships. Relationship groups: Access control policies can specify that a user must fulfill a particular relationship with respect to the resource being accessed, or they can specify that a user must fulfill the conditions specified in a relationship group. In most cases, a relationship is sufficient. However, if more complex relationships are needed, a relationship group can be used instead. A relationship group enables you to specify multiple relationships and also a chain of relationships. Both of these are done using a relationship chain construct. A relationship chain is a construct that can express a simple relationship (directly between a user and the resource), but can also be used to express a series of relationships between the user and the resource. For example, to express that a user must have a role in an organization that has a relationship (other than the owner relationship) with the resource, use a relationship group. In this example, there is a role relationship between the user and the organization, and a relationship between the organization and the resource. // Clear related topics |
 ibm.com/redbooks |