|
|
The following topics are covered in this section:
To write and deploy a set of policies, perform the following tasks (see Figure 3-1):
Task 1: Define the security requirements for your business. Understand the functions of your applications and the various types of users who need to access them under different circumstances.
Task 2: Define resources. Determine that resources you want to protect and define them in a resource tree. Resources include the resources to be protected, the resource attributes, the actions that will be used to access the resources, and, optionally, action groups.
Task 3: Define an identity directory and the identity attributes, users, groups, and roles that are to make up the directory.
Task 4: Define declarations to use with the resources and identities and as constraints in authorization policies, role mapping policies, and delegation policies.
Task 5: Write role mapping policies that control which users and groups have membership in specific roles, under what constraints, and on which resources.
Task 6: Write authorization policies to define what actions apply to each resource, under what conditions, and which roles a user or group must have membership in to be granted the defined action to the specified resource.
Task 7: Bind the top-level resource and the identity directory to the authorization and role mapping providers configured in the security configuration. By doing this you choose which Security Service Module (SSM) enforces policies for these resources.
Task 8: Deploy the set of policies to the SSM. The SSM starts to enforce policies only after the policies are deployed.
While the subsequent sections of this document describe how to use the Entitlements Administration Application to define and manage role mapping policies and authorization policies, you may also use the Business Logic Manager (BLM) as it offers the same capabilities.
AquaLogic Enterprise Security provides the following services and components for securing access to resources:
The authentication service is responsible for authenticating the user. There are two ways a user can be authenticated.
You can configure multiple authentication services to authenticate, assert identity, and collect additional group or attribute information at authentication time.
Once the user is authenticated, the service will create a subject object. The subject can contain one or more user principles with attribute information, one or more group principles for the groups in which the user has membership, and any attributes associated with those groups. The subject is provided to the authorization and role mapping services.
Given the subject, which is provided by the authentication service, the role mapping service evaluates the role mapping policies to determine if a user or group is granted a role on the requested resource. Roles provide a level of abstraction between users and the actions they have in a given context (within an application). Membership rules can be time-based so that users can delegate their actions for a limited time (for example, when they go on vacation). Roles are always associated with resources and can be granted broadly or within the context of a particular application resource.
The actual authorization decision (isAccessAllowed) is made based on identity, group, or role membership.
The authorization service evaluates access control policies to determine what a user can do on a particular resource. Policies can include constraints that the authorization service evaluates against static data (such as user attributes retrieved when a user is authenticated) or dynamic data retrieved at runtime when the policy is evaluated. Further, the authorization service can take application context (for example, EJB parameter values) into account at evaluation time. The authorization service can return authorization decisions or entitlements through the report function.
The authorization service supports the use of multiple authorization providers. This allows you to use ALES in conjunction with an existing entitlements system. When multiple authorization providers are used, a custom adjudicator is required to determine the outcome when conflicts occur between these providers.
The credential mapping service provides a mechanism to address single sign-on to enterprise systems. This service can map user identity to an appropriate set of credentials for authentication to enterprise applications, such as PeopleSoft, SAP, and relational databases. This service can also be used to remove the need to embed credentials within application code. ALES can support a number of identity token formats, such as SAML, to represent the user’s identity.
At runtime, the ASI Authorizer, located in the Security Service Module instance where the polices are deployed, uses role mapping policies and authorization policies to make decisions that grant or deny access to users.
| Note: | The ASI Authorizer is also known as the Authorization and Role Mapping Engine (ARME). |
Figure 3-2 shows the access control decision process. As illustrated, before you can write policies to define access control for your business resources, you must define those resources, the associated user identity, and any custom declarations you may want to use. Once resources and user identify are defined and the policies are written, they do not take effect until they are bound to the Authorization and Role Mapping providers in the deployed Security Service Module (SSM). At runtime, user requests to perform actions on specific resources are evaluated to determine whether the user is granted the requested access.
Policies control what actions users can perform on resources. A set of policies can be applied to a single resource, an entire application, or implemented globally as a structured collection of entitlements for an organization representing the superset of all of your application policies.
The following sections describe how to write security policies using the Entitlements Administration Application:
Figure 3-3 shows how the Entitlements Administration Application represents the various policy components. You use the Resources, Identity, Policy, and Declarations nodes to write policy. Then you use the Save button to save and deploy the policy set and the security configuration to the SSM.
Resources are displayed in a hierarchical tree called a resource hierarchy. A page generated from a Java Server Page (JSP) is an example of an application resource. The page can call EJBs or COM resources to execute some business logic. The back office services that transfer money between accounts, issue a payment, or run a report are also resources, although they may not appear on the web page or execute on the application server.
An administrator may define as many resources and levels in the hierarchy as needed to represent data, services, and system components within an application.
Individual resources in the hierarchy are also called nodes and the type of node can convey additional information about the resource. Table 3-1 lists and describes the types of nodes that you can configure using the Entitlements Administration Application.
Any resource at or above a binding node can be configured as a distribution point for policies. When a distribution (or deployment) is initiated, you can distribute all updates (by selecting the root node) or limit which updates are distributed by selecting resources using the nodes that are configured as distribution points. Only updates that were made at and below the selected nodes are distributed.
For instructions on managing resources, open the Entitlements Administration Application’s help system and select Resources in the navigation pane.
Some typical resources that you might want to secure, include:
The following topics provide more information on configuring resources:
Any resource defined in the resource tree can be configured as a virtual resource. Once you configure a resource to allow virtual resources, its child resources are protected by the same policies as the parent, even if they do not appear in the resource tree. For example, given a resource hierarchy URL such as http://www.myname.com/private/dir1/dir2/, if you create the resource tree up to http://www.myname.com/private and then configure private to allow virtual resources, dir1 and dir2 are automatically protected by the access control policies you assign to private, without having to add dir1 and dir2 as explicit resources on the resource tree or assigning them explicit policies.
To configure a resource as virtual, select the resource in the resource tree. Then click Modify in the lower part of the left pane. When it displays in the right pane, select the Allow Virtual Resource checkbox.
All resources can have attributes that store information about the resources to which they belong. For example, you may create resource attributes to specify resource owner, type of resource, creation date, and so on.
Attributes are inherited by child resources from their parent. If a resource explicitly sets the value of an attribute, this value overrides the inherited one.
When you select a resource in the resource hierarchy, its attributes display in the right pane.
A action is some action that can be performed on a resource. For instance, execute is a typical application action; and read and write are typical file system actions. You can use the actions provided or you can create your own. A related collection of actions may be organized into a action group for management purposes.
A action group allows you to organize actions into logical groups for ease of management. For example, it is common to define a action group that applies to a particular application or set of transactions. Action groups can be used as filters when constructing policies, although they cannot appear directly in a policy. Figure 3-5 shows an example of how action groups and their associated actions appear in the Entitlements Administration Application.
To view the out-of-box actions and action groups provided when ALES is installed, select the Actions node in the left pane. The right pane provides the Action tab for managing actions and the Action Groups tab for managing actions. In Figure 3-5, the Action tab is selected.
For instructions on managing actions and action groups, open the Entitlements Administration Application’s help system and select Actions and Action Groups in the navigation pane.
Although BEA AquaLogic Enterprise Security provides tools to manage users and groups locally, they are typically managed through an external repository, such as a Lightweight Directory Access Protocol (LDAP) directory server or a network database. User and group information, along with any attributes, is stored as metadata in the policy database and is then available for viewing directly through the Entitlements Administration Application.
As shown in Figure 3-6, each defined identity directory displays under the Identity node in the Entitlements Administration Application’s left pane.
When you select an identity directory, the right pane contains three tabs for managing Users, Groups, and Attributes.
For instructions on managing identities, open the Entitlements Administration Application’s help system and select Identity in the navigation pane.
A group is a logical collection of users that share some common characteristics, such as department, job function, or job title. For example, a company may separate its sales staff into two groups, Sales Representatives and Sales Managers, because they want their sales personnel to have different levels of access to resources depending on their job functions.
A group can contain either users or other groups; users who are assigned to a group are called group members. Nested memberships of groups within a group form a hierarchy. Group membership can be assigned only from within the same directory. Groups have a static identity that an administrator assigns.
Managing groups is more efficient than managing large numbers of users individually. By using groups, you do not need to define an access control policy for each and every user. Instead, each user in the group inherits the policies applied to the group; this rule also applies to nested groups. Granting a permission or role to a group is the same as giving that permission or role to each user who is a member of the group. For example, an administrator can specify roles for 50 users at one time by placing the users in a group, and then granting that group the role on a given resource.
Figure 3-8 shows how groups are represented in the Entitlements Administration Application. Notice that the BankTellers group contains four members.
For instructions on managing groups, open the Entitlements Administration Application’s help system and expand Identity>Groups in the left navigation pane.
A user corresponds to an individual who makes a request to access a resource, although a user can be an automated process that accesses the system. Users are included in an authorization policy by assigning users to groups, and then assigning that group to a role or assigning the users directly to roles. Each user within a directory must have a unique identity, or user name.
Users can be associated with certain characteristics, referred to as identity attributes; these attributes store information about the user. The list of attributes that can be set for a user is dictated by the attribute schema of the directory to which the user belongs. Figure 3-9 shows an example of a user representation with identity attributes.
For instructions on managing users, open the Entitlements Administration Application’s help system and expand Identity>Users in the left navigation pane.
Identity attributes are represented under the Identity in the Entitlements Administration Application (see Figure 3-6). Each user and group can have different characteristics defined as identity attributes. The type of information or attributes collected—a method typically referred to as profiling—also varies and typically includes information such as name and address, phone, e-mail address, personal preferences, and so forth. Identity attributes can be extracted from the external data source.
An identity attribute is declared specifically to contain identity information. An attribute value can be used in policies to set limits for that user. Attributes provide a very powerful way to refer to users and groups indirectly in policies, which results in a more dynamic and versatile policy set.
For instructions on managing identity attributes, open the Entitlements Administration Application’s help system and expand Identity>Identity Attributes in the left navigation pane.
A role is a dynamic alias used to associate users and groups to role-based functional responsibilities. A role represents a collection of actions on a resource. Roles are computed and granted to users or groups dynamically based on conditions, such as user name, group membership, identity attributes, or dynamic data, such as the time of day. Roles membership can apply to only specific resources within a single application or can be applied globally across the enterprise. A role can also be delegated from one user to another user. Multiple users or groups can be granted a single security role. Figure 3-10 shows an example of a roles representation in the Entitlements Administration Application.
For instructions on managing roles, open the Entitlements Administration Application’s help system and select Roles in the left navigation pane.
A set of policies can include two types of policies: role mapping policies and authorization polices:
For more information about policies, refer to the following topics:
Membership rules are used to grant users or groups membership into a given role. The membership can be limited based on a number of items including the resource hierarchy, subjects (users and groups), constraints, and delegator. A role mapping policy with the delegate action, delegates a role granted to one user (the delegator) on a resource to another user or group. A role cannot be delegated to a role. Figure 3-11 shows two role mapping policies in the Entitlements Administration Application’s right pane.
For instructions on managing role mapping policies, open the Entitlements Administration Application’s help system and select Policies>Membership Rules in the left navigation pane.
Authorization policies determine what actions can be performed on a resource. Authorization policies are typically written to grant specific actions upon specific resources to a role with a defined set of constraints. An authorization policy can define actions, resources, subjects (users, groups, and roles), constraints, and delegators.
For instructions on managing authorization policies, open the Entitlements Administration Application’s help system and select Policies>Authorization Policies in the left navigation pane.
Entitlements Administration Application provides support for generating role mapping policy reports and authorization policy reports.
You can use role mapping policy reports to create a role mapping policy inquiry and use it to generate a report that you can use for analysis. You can define inquiries that include a policy subject list (user and group), a role list, a resource list, and a delegator list. Role mapping policy inquiries ask the question, “What role is granted to a user or group scoped to a particular resource?”.
| Note: | In the Entitlements Administration Application, role mapping reports are exposed as ‘membership rule reports’. |
For example, let us say that you want to find out who can access a particular resource. You can run a policy inquiry that includes a resource and an Effect type of GRANT. Such an inquiry produces a complete list of the roles that will be granted to any subject during access to the defined resource. To narrow the inquiry you can add roles, subjects (users and groups) and delegators to the inquiry definition. See Figure 3-12 shows the results of a role mapping policy report.
For instructions on managing role mapping policy reports, open the Entitlements Administration Application’s help system and select Policy Reports in the left navigation pane.
You can use authorization policy reports to create an authorization policy inquiry and use it to generate a report that you can use for analysis. Authorization policy inquiries search for action-based policies that match specified characteristics exactly. You can define inquiries that include a policy subject list (user, group and role), an action list, a resource list, and a delegator list. Authorization policy inquiries ask this question, “Who can do what to what resource?”.
For example, let us say that you want to find out who has GRANT access to a resource, you can run a policy inquiry that includes a resource and an Effect type of GRANT. Such an inquiry produces a complete list of the users for any subject for any role on the defined resource that has a GRANT action type. To narrow the inquiry you can add actions, subjects (users, groups, and roles) and delegators to the inquiry definition.
For instructions on managing role mapping policy reports, open the Entitlements Administration Application’s help system and select Policy Reports in the left navigation pane.
A declaration is a variable that represents either a predefined value (for example, days of the week) or a value that is dynamically defined at runtime (for example, the date). To help you design efficient policies, various built-in declarations are provided for your use.
There are three types of declarations:
For instructions on managing declarations, open the Entitlements Administration Application’s help system and select the Constants, Dynamic Attributes, or Evaluation Functions in the left navigation pane.
Policies set must be bound to the authorization and role mapping providers that are configured for the SSM being used to protect your application resources. In the Entitlements Administration Application this is performed as follows:
To secure resources, both the SSM configuration and the policies must be deployed to the SSM being used to securing the application. Whenever configuration and policy changes are made, they must be distributed to the SSM.
To distribute policies to the SSM using the Entitlements Administration Application:
After the distribution, you can view the results of the policy distribution by clicking on Distribution Status tab in the right pane. Figure 3-14 shows the expanded Deployment node in the Entitlements Administration Application.
|
