|
|
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 which resources you want to protect and define them in a resource tree. Resources include the resources to be protected, the resource attributes, the privileges, or actions, that will be used to access the resources, and, optionally, privilege 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 which privileges apply to each resource, under what specific conditions, or constraints, and which roles a user or group must have membership in so as to be granted the defined privilege 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 Administration Console to define and manage role mapping and authorization policies, you may also use the Business Logic Manager (BLM) as it offers the same capabilities.
For a user to gain access to a resource, AquaLogic Enterprise Security provides the following services and components:
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 privileges that they have in a given context (within an application). Role mapping policies can be time-based so that users can delegate their privileges for a limited time (for example, when they go on vacation). Roles are always associated with resources and can be granted broadly or granted only in the context of a particular application resource.
The actual authorization decision is made (isAccessAllowed) 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 that are retrieved when a user is authenticated. The authorization service can also evaluate constraints against dynamic data that is 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. ALES can be used to add new capabilities while preserving the existing access control logic. When multiple authorization providers are used, a custom adjudicator is required to determine the outcome when conflicts occur between authorization providers.
The credential mapping service provides a mechanism to address enterprise single sign-on to enterprise systems. This service can map user identity to an appropriate set of credentials for authentication to enterprise applications like 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, which is also known as the Authorization and Role Mapping Engine (ARME))—located in the Security Service Module instance on which the polices are deployed—uses the role mapping, authorization, and delegation policies to make access control decisions and grant or deny access to users.
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, optionally, 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 a Security Service Module (SSM) configuration and deployed. At runtime, user requests to perform actions on specific resources are processed using role-based access control (RBAC) to determine whether the user is granted the requested access (isAccessAllowed).
A set of 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 your organization, representing the superset of all of your application policies.
The following sections describe the components of AquaLogic Enterprise Security policies as presented in the Administration Console and how to write security policies using the Administration Console:
Figure 3-3 shows how the Administration Console represents the various policy components. You use the Security Configuration node to configure security providers for the SSM and to bind the set of policies to the security configuration. You use the Resources, Identity, Policy, and Declarations nodes to write policy. Then you use the Deployment node to deploy the policy set and the security configuration to the SSM.
A resource is a general term that refers to an entity or group of entities that you can protect. Resources can include applications, data, or system components. Resources may also include background services with which the user has no direct interaction.
Figure 3-4 shows the expanded Resource node in the Administration Console.
Clicking Resources displays all of the resources that are defined in the right pane (see Figure 3-5).
The Administration Console displays resources in a tree structure 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 Administration Console.
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 choose to distribute either all updates (by selecting the root node) or you can 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.
Some typical resources that you might want to secure, include:
For instructions on how to define a resource, log into the Administration Console, access the Console Help, find Resources in the left pane, and click Creating a Resource.
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, any resources below it, that is, its child resources, are, in effect, virtual resources and are protected by the same policies as their parent, even though 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 a resource in the resource tree, click Configure, and check the Allow Virtual Resources check box.
A resource attribute is represented under Resources in the Administration Console (see Figure 3-4). All resources can have attributes, which 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 for an attribute, this value overrides the inherited one.
For instructions on how to create a resource attribute, log into the Administration Console, access the Console Help, find Resource Attributes in the left help pane, and click Creating a Resource Attribute.
A privilege is represented by the key icon in the Administration Console (see Figure 3-4) and is an action that you can perform on a resource. For instance, execute is a typical application privilege; and read and write are typical file-system privileges.
You can use the privileges provided or you can create your own. Figure 3-6 shows how privileges appear in the Administration Console. Notice that each privilege refers to an action. A related collection of privileges may be organized into a privilege group for management purposes.
For instructions on how to create privileges, log into the Administration Console, access the Console Help, find Resources > Privileges in the left help pane, and click Creating a Privilege.
A privilege group is represented by the keys icon in the Administration Console (see Figure 3-4) and allows you to organize privileges into logical groups for ease of management. For example, it is common to define a privilege group that applies to a particular application or set of transactions. Privilege groups can be used as filters when constructing policies, although they cannot appear directly in a policy. Figure 3-7 shows an example of how privilege groups and their associated privileges appear in the Administration Console.
For instructions on how to create privilege groups, log into the Administration Console, access the Console Help, find Resources > Privilege Groups in the left help pane, and click Creating a Privilege Group.
The Identity icon represents your directories and user communities in the Administration Console (see Figure 3-8). 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 Administration Console.
Figure 3-8 shows the expanded Identity node in the Administration Console.
A directory typically represents groups of users of a particular application or resource, or users in a specific location. Each directory has an associated attribute schema. The schema defines the attributes applied to members of the directory. Figure 3-9 shows how directories are represented in the Administration Console. In this example, there is one directory: asi and test. The test directory shows the attributes that are stored for each member of the directory.
For instructions on how to create directories, log into the Administration Console, access the Console Help, find Identity in the left help pane, and click Creating a Directory.
For more information on configuring identity policy elements, see the following topics:
Identity attributes are represented under the Identity in the Administration Console (see Figure 3-8). 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.
Figure 3-10 shows how identity attributes are represented in the Administration Console.
For instructions on how to create identity attributes, log into the Administration Console, access the Console Help, find Identity Attributes in the left help pane, and click Creating an Identity Attribute.
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-11 shows how groups are represented in the Administration Console. Notice that the BankTellers group contains four members.
For instructions on how to create groups, log into the Administration Console, access the Console Help, find Identity > Groups in the left help pane, and click Creating a Group.
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-12 shows an example of a user representation with identity attributes.
For instructions on how to create users, log into the Administration Console, access the Console Help, find Identity > Users in the left help pane, and click Creating a User.
A role is a dynamic alias used to associate users and groups to role-based functional responsibilities. A role represents a collection of privileges 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-13 shows an example of a roles representation in the Administration Console.
For instructions on how to create roles, log into the Administration Console, access the Console Help, find Identity > Roles in the left help pane, and click Creating a Role.
A set of policies can include three types of policies: role mapping policies, authorization polices, and delegation policies:
Figure 3-14 shows the expanded Policy node in the Administration Console.
| Note: | Delegation policies that assign roles are listed in the console with role mapping policies. Delegation policies that assign privileges are listed in the console with authorization policies. Delegation policies are distinguished by the Effect type of DELEGATE as oppose to GRANT or DENY. |
For more information about policies, refer to the following topics:
Role mapping policies determine how roles are granted, and to which a user or group can be assigned. Role mapping policies 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 delegation policy that delegates a role assigns a role granted to one user (the delegator) on a resource to another user or group. A role cannot be delegated to a role. See Figure 3-14 for an illustration of how role mapping policies are represented in the Administration Console.
For instructions on how to write role mapping policies, log into the Administration Console, access the Console Help, find Policy > Role Mapping Policies in the left help pane, and click Creating a Role Mapping Policy.
Authorization policies determine what actions can be performed on a resource. Authorization policies are typically written to grant specific privileges upon specific resources to a role with a defined set of constraints. An authorization policy can define privileges, resources, subjects (users, groups, and roles), constraints, and delegators. A delegation policy that delegates a privilege assigns the privileges granted to one user (the delegator) on a resource to another user, group, or role. See Figure 3-14 for an illustration of how authorization policies are represented in the Administration Console.
For instructions on how to write authorization policies, log into the Administration Console, access the Console Help, find Policy > Authorization Policies in the left help pane, and click Creating an Authorization Policy.
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 this question, What role is granted to a user or group scoped to a particular resource?
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-14 for an illustration of how role mapping policy reports are represented in the Administration Console.
For instructions on how to create role mapping policy reports, log into the Administration Console, access the Console Help, find Policy > Role Mapping Policy Reports in the left help pane, and click Creating a Role Mapping Policy Report Inquiry.
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 privilege-based policies that match specified characteristics exactly. You can define inquiries that include a policy subject list (user, group and role), a privilege 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 with a privilege type of GRANT 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 users for any subject for any role on the defined resource that has a GRANT privilege type. To narrow the inquiry you can add privileges, subjects (users, groups, and roles) and delegators to the inquiry definition. See Figure 3-14 for an illustration of how authorization policy reports are represented in the Administration Console.
For instructions on how to create authorization policy reports, log into the Administration Console, access the Console Help, find Policy > Authorization Policy Reports in the left help pane, and click Creating an Authorization Policy Report Inquiry.
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.
Figure 3-15 shows the expanded Declarations node in the Administration Console.
There are four types of declarations:
For instructions on how to create the different types of declarations, log into the Administration Console, access the Console Help, find Declarations in the left help pane, and click the following topics:
You can use the Administration Console to write and deploy a set of policies to protect application resources. A policy set can include role mapping policies, authorization policies, and delegation policies that, taken together, define who has access to which resources. You design and write policies to satisfy the resource access control requirements of your business. Once written, the policy set must be bound to the authorization and role mapping providers that are configured for the SSM that you will use to protect your application resources.
To use the Administration Console to bind the policies to the authorization and role mapping providers, perform the following steps:
| Note: | If you have not bound the Security Service Module, open the Unbound Configuration folder that contains the providers you want to configure. |
The Authorization page appears.
//app/resource) you defined the top-level resource, and click Save.Once you have designed your policies and configuration, you need to deploy them to the SSM so that they can be used to protect your resources. You must distribute both policy and configuration data before they can take effect. You can distribute policy data and configuration data together, or you can distribute only configuration data as structural changes. After a configuration update, you must restart the SSM for the new configuration to take effect.
Before you distribute policies, you choose the distribution point. The distribution point identifies what portions of the policy updates are distributed.
After the distribution, you can view the results of the policy distribution by clicking on Distribution Results and Deployment Status. Figure 3-16 shows the expanded Deployment node in the Administration Console.
For more information about deployment and instructions on how to distribute policy data and configuration information, log into the Administration Console, access the Console Help, find Deployments in the left help pane, and click the following topics:
|