How to implement access control in customized code?

Enterprise beans and data beans are resources that may need to protect. However, not all Enterprise bean and data beans should be protected.

Typically, the question of what to protect comes into play when you create new Enterprise beans and data beans.

Decide which resource to protect depends on your application.

If a command returns an Enterprise bean in the getResources method, then the Enterprise bean must be protected because the ACP manager will call the getOwner() method on the enterprise ban. The fulfills() method will also be called if a relationship is specified in the corresponding resource-level ACP.

if we implements the protectable interface for all of enterprise bean and data bean ( in number of policy increase) performance may degrade.

Primary resources should be protected, but dependent resources often do not require protection. if user allowed to access a primary resource, it makes sense that, by default, the user should also be allowed to access its dependent resource.

Understanding Access Control Policy

Access control in WCS is composed of the following elements:

1. Users - Users are the people that use the System. so users must be grouped into relevent access group.

2. Actions - Actions are the activities that users can perform on the resource. so action must also be grouped into relevent action groups.

3. Resources - Resources are the entities that are protected. Ex: if the action is a view, the resource to be protected is the command that invoked the view.

4. relationships - are the relationship between the user and the resource.

There are two level/type ACP.

1. Command-level ACP - The first level of ACP is performed by the WAS. In this respect, WC uses WAS to protect Enterprise beans and servlets.

2. Resource-level ACP - The Second level ACP is the fine-grained access control system of WCS.

Note: A command-level ACP alwasy has the ExecuteCommandActionGroup as the action group for Controller command. for views, the resource group is always ViewCommandResourceGroup. (ACPOLICY, MBRGRP, MBRGRPCOND, ACACTGRP, ACRESGRP)

ACP are enforced by the access control policy manager. when a user attempts to access a protected resource, ACP manager determines what ACP are applicable for that protected resource, and based upon the applicable ACP, it determines if the user is allowed to access the requested resources.

An ACP is a 4-element that is stored in the ACPOLICY table. Each access control policy takes the following form:

AccessControlPolicy [UserGroup, ActionGroup, ResourceGroup, Relationship]

The above elements say, a user belonging to a specific user group is permitted to perfrom action in the specified ActionGroup on resource belonging to the specified ResourceGroup, as long as the user satisfies the conditions specified in the Relationship or relationship group, with respect to the resource in question.

Ex: [AllUsers, UpdateDoc, doc, creator] specifies that all users can update a document, if they are the create of the document.

• The user group is a specific type of member group that is defined in the MBRGRP table.
• A user group must be associated with member group type of -2. the value of -2 represent an access group and is defined in the MBRGRPTYPE table.
• Association between the usergroup and membergroup type is stored in the MBRGRPUSG table.

The membership of a user into a particular user group may be stated explicitly or implicitly. An explicit specification occurs if the MBRGRPMBR tables states that user belongs to a particular member group. An implicit specification occurs fi the user satisfies a condition (all users that fulfill the role of Product Manager) that is stated in the MBRGRPCOND table.

Most conditions to include a user in a user group are based upon the user fulfilling a particular role. Ex: there could be ACP that allows all users that fulfill the Product Manager role to perform catalog management operations. in this case, any user that has been assigned the Product Manager role in the MBRROLE table is implicitly included in the user group.

The ActionGroup elements comes from the ACACTGRP table. An action group refers to an explicitly specified group of actions. The list of actions is stored in the ACACTION table and the relationship of each action to its action group(or group) is stored in the ACACTACTGP table.

An example of an action group is the "OrderWriteCommands" action group. this action group includes the following action that are used to update orders

• OrderDeleteCmd
• OrderCancelCmd
• OrderAProfileUpdateCmd
• OrderUnlockCmd
• OrderScheduleCmd
• ScheduledOrderCancelCmd
• ScheduledOrderProcessCmd
• OrderItemAddCmd
• OrderItemDeleteCmd
• OrderItemUpdateCmd
• PayResetPMCmd

The resource group is mechanism to group together particular types of resources. membership of a resource in a ResourceGroup can be specified in one of two ways.

using the conditions column in the ACRESGRP table
using the ACRESGPRES table.

in most case, it is sufficient to use the ACRESGPRES table for associating resources to resource group. using this method, resources are defined in the ACRESCGRY table suing their java class name.

These resources are associated with appropriate resource group(ACRESGRP) using the ACRESGPRES association table. in this case where the java class name alone is not sufficient to define the members a resource group.

The ACP can optionally include either a Relationship or RelationshipGroup element as its fourth element.

if ACP uses a Relationship element, this come from the ACRELATION table. if on other hand, it includes a RelationshipGroup Element, that comes from the ACRELGRP table. A ReletionshipGroup specification from the ACRELGRP table takes precedeence over the Relationship information from the ACRELATION table.