Skip navigation.

Policy Managers Guide

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Writing Policies

The following topics are covered in this section:

 


Policy Implementation Tasks

To write and deploy a set of policies, perform the following tasks (see Figure 2-1):

  1. Task 1: Define security requirements for your business.
  2. 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.
  3. Task 3: Define an identity directory and the identity attributes, users, groups, and roles that are to make up the directory. Optionally, metadirectories can be used to import user identities from remote repositories.
  4. Task 4: Define declarations to use with the resources and identities and as constraints in authorization policies, role mapping policies, and delegation policies.
  5. Task 5: Write role mapping policies that control which users and groups have membership in specific roles, under what constraints, and on which resources.
  6. 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.
  7. 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.
  8. Task 8: Deploy the set of policies to the SSM. The SSM starts enforcing policies only after they are deployed.
  9. Figure 2-1 Policy Implementation Tasks

    Policy Implementation Tasks


     

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.

 


Using the Administration Console to Write Policies

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 you write security policies using the Administration Console:

Administration Console Overview

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—modeled on your security requirements of your business—that taken together define who has access to which resources.

Figure 2-2 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.

Figure 2-2 Administration Console

Administration Console


 

Defining Resources

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 2-3 shows the expanded Resource node in the Administration Console.

Figure 2-3 Expanded Resource Node

Expanded Resource Node


 

Clicking Resources displays all of the resources that are defined in the right pane (see Figure 2-4).

Figure 2-4 Defined Resources

Defined Resources


 

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.

Individual resources in the hierarchy are also called nodes and the type of node can convey additional information about the resource. Some nodes are organizational because they represent a logical grouping of resources. For example, an organizational node called accounting may represent all resources in the accounting department. A node representing a group of resources is represented by a blue resource icon Defined Resources .

Another type of organizational node is an application node represented by a green resource icon Defined Resources . This icon depicts a collection of resources that provide a specific set of services. However, an application node can also be used to represent an application with a single component, such as a desktop spreadsheet application.

Individual resource nodes are represented by the Defined Resources icon, and typically represent an individual resource that can be protected. An administrator may define as many resources and levels in the hierarchy as needed to represent data, services and system components within an application.

A special node, called a binding node, is depicted by a resource or application node with a small red diamond Defined Resources . A binding node is used to associate (or bind) a subset of the resource tree to a particular SSM.

Any resource at or above a binding node can be marked as a policy distribution point. When a policy distribution 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 from the existing distribution points. Only updates that were made at or below the selected distribution points 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 help pane, and click Creating a Resource.

The following topics provide more information on configuring resources:

Resource Attributes

A resource attribute is represented by the Defined Resources icon in the Administration Console (see Figure 2-3). All resources can have attributes, which store information about the resources to which they belong. Common resource attributes might be a file type, resource owner, or the creation date. 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.

Privileges

A privilege is represented by the key Defined Resources icon in the Administration Console (see Figure 2-3) 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 2-5 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.

Figure 2-5 Privileges Representation in the Administration Console

Privileges Representation in the Administration Console


 

Privilege Groups

A privilege group is represented by the keys Privileges Representation in the Administration Console icon in the Administration Console (see Figure 2-3) 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 2-6 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.

Figure 2-6 Privilege Groups Representation in the Administration Console

Privilege Groups Representation in the Administration Console


 

Defining Identities

The Identity Privilege Groups Representation in the Administration Console icon represents your directories and user communities in the Administration Console (see Figure 2-3). 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. A virtual view of identity data can be created through the replication and synchronization of the data using the metadirectory tools. User and group information, along with any attributes, is then stored as metadata in the policy database and is then available for viewing directly through the Administration Console.

Figure 2-7 shows the expanded Identity node in the Administration Console.

Figure 2-7 Expanded Identity Node

Expanded Identity Node


 

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 2-8 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.

Figure 2-8 Directory Representation in the Administration Console

Directory Representation in the Administration Console


 

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

Identity attributes are represented by the Directory Representation in the Administration Console icon in the Administration Console (see Figure 2-7). 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 2-9 shows how identity attributes are represented in the Administration Console.

Figure 2-9 Identity Attributes Representation in the Administration Console

Identity Attributes Representation 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.

Groups

A group is represented by the Identity Attributes Representation in the Administration Console icon in the Administration Console (see Figure 2-7) and 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 2-10 shows how groups are represented in the Administration Console. Notice that the BankTellers group contains four members.

Figure 2-10 Group Representation in the Administration Console

Group Representation in the Administration Console


 

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.

Users

A user is represented by the Group Representation in the Administration Console icon in the Administration Console (see Figure 2-7) and 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 2-11 shows an example of a user representation with identity attributes.

Figure 2-11 User Representation in the Administration Console

User Representation in the Administration Console


 

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.

Roles

Roles are represented by the User Representation in the Administration Console icon in the Administration Console (see Figure 2-7). 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 2-12 shows an example of a roles representation.

Figure 2-12 Roles Representation in the Administration Console

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.

Metadirectory

Metadirectories are represented by the Roles Representation in the Administration Console icon in the Administration Console (see Figure 2-7). You can use a metadirectory to extract user data from your user repository (for example, an LDAP server, an Active Directory, a database server, or NT Domain directory) and import that data into the policy database. As a result, the user, group, roles, and attributes are available and synchronized, and can be used to enforce dynamic security policies in your applications through the ASI Authorization and ASI Role Mapping services.

For instructions on how to configure metadirectories, log into the Administration Console, access the console Help, find Identity-->Metadirectories in the left help pane, and click Configuring a Metadirectory.

For more information on configuring a metadirectory, see Configuring Metadirectories in the Integrating ALES with Application Environments.

Writing Authorization and Role Mapping Policies

The policy node is represented by the Roles Representation in the Administration Console icon in the Administration Console (see Figure 2-3). A set of policies can include three types of policies: role mapping policies, authorization polices, and delegation policies. Role mapping policies, at a minimum, are written to create roles that define what policy subjects (user and groups) are assigned to the role for what resources. Role mapping policies can also include constraints. Authorization policies are written against resources to define what policy subjects (users, group, or roles) have what privileges on what resources. Authorization policies can also include constraints. Delegation policies are used to assign privileges or roles granted to one user to another user.

Figure 2-13 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.

Figure 2-13 Expanded Policy Node

Expanded Policy Node


 

For more information about policies, refer to the following topics:

Role Mapping Policies

Role mapping policies are represented by the Expanded Policy Node icon in the Administration Console (see Figure 2-13) and displays the policies that 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, policy 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.

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

Authorization policies are represented by the Expanded Policy Node icon in the Administration Console (see Figure 2-13) and displays the policies that 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 represented by a blue check mark Expanded Policy Node icon in the Administration Console. An authorization policy can define privileges, resources, policy 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.

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.

Role Mapping Policy Reports

Role Mapping policy reports are represented by the Expanded Policy Node icon in the Administration Console (see Figure 2-13). Using this function you can 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 simply 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.

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.

Authorization Policy Reports

Authorization policy reports are represented by the Expanded Policy Node icon in the Administration Console (see Figure 2-13). Using this function you can 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 simply 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, policy subjects (users, groups, and roles) and delegators to the inquiry definition.

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.

Defining Declarations

Declaration are represented by the Expanded Policy Node icon. 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 (the date). To help you design efficient policies, various built-in declarations are provided for your use.

Figure 2-14 shows the expanded Declarations node in the Administration Console.

Figure 2-14 Expanded Declarations Node

Expanded Declarations Node


 

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:

Binding Policies

To use the Administration Console to bind the Security policy to the authorization and role mapping providers, perform the following steps:

  1. Open the Security Configuration folder.
  2. Open the Service Control Manager folder that contains the Security Service Module whose providers you want to configure or change.
  3. Open the Security Service Module folder that contains the providers you want to configure or change.
  4. Note: If you have not bound the Security Service Module, open the Unbound Configuration folder that contains the providers you want to configure.

  5. Open the Authorization folder, and click Authorization.
  6. The Authorization page appears.

  7. Click the Details tab, enter identity directory you defined when you define the user identities and the application deployment parent (//app/resource) you defined the top-level resource, and click Save.

Deploying Policies

Deployment is represented by the Expanded Declarations Node icon in the Administration Console. Once you have designed and tested your security policy and configuration, you need to deploy so the policy and configuration take effect in your environment. When you distribute policy, you choose the distribution point for the policy before you actually distribute it. The distribution point identifies what portions of the policy updates are made active in your environment. After the distribution, you can view the results of the policy distribution. You also distribute security configuration data. After a configuration update, you must restart the SSM to make use of the new configuration.

Figure 2-15 shows the expanded Deployment node in the Administration Console.

Figure 2-15 Expanded Deployment Node

Expanded Deployment Node


 

The Deployment Status page allows you to gather information regarding policy and configuration deployments. The page shows whether any components are out of synchronization with the Administration Application.

For instructions on how to distribute policy, log into the Administration Console, access the console Help, find Deployments in the left help pane, and click the following topics:

 

Skip navigation bar  Back to Top Previous Next