|
|
This section covers the following topics:
You manage security by using the Administration Console to configure Service Control Managers, Security Service Modules and their providers, and to design, edit, and distribute access control policy. A policy is composed of a set of authorization and role mapping policies, modeled on your organizational business requirements that state who has access to which resources.
The policies that define your access control policy are built from policy elements: identity (users and groups with their associated attributes), privileges, roles, and the resources you want to protect. A policy can be applied to either a single resource or to many resources across the enterprise. An enterprise-wide policy represents the superset of all of your authorization and role mapping policies. The following sections describe security management concepts and how you implement security using the Administration Console:
Figure 5-1 shows how the Administration Console represents the various policy elements and resources. The resources shown here represent the initial policy settings used to protect the console.
A Security Configuration is represented by the 
icon in the Administration Console, and consists of one or more Service Control Managers, one or more Security Service Modules represented by the 
icon, and the providers associated with each module. You can use the security providers that are provided, purchase custom security providers from third-party security vendors, or develop your own custom security providers. Table 5-1 shows how each provider type is represented in the Administration Console.
To learn more about security providers and their services, see Architecture Overview. For information on how to develop custom security providers, see Developing Security Providers for AquaLogic Enterprise Security.
A configuration is a named collection of elements and security services over which a common and consistent set of policies are administered in a coordinated fashion. Each configuration has a unique Configuration ID and is bound to a Service Control Manager. Applications that use the same Configuration ID reference the same user communities, policy, and security configuration.
A configuration also defines the method of authentication and authorization used to provide access to a resource for one or more users and groups. The authorization policy protects the resource against unauthorized access. Each Security Service Module has a Configuration ID associated with it that defines the security providers, policy, and settings for that Security Service Module.
A resource is a general term that refers to any object 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. For example, a bank might offer banking services on a web page that simulate the actions of a teller. The components (buttons, tables, data fields) displayed on that web page are all resources. The Administration Console displays resources in a tree structure called a resource hierarchy as shown in Figure 5-2. The resources shown here represent the administration services and policy data elements that are accessible to the Administration Server on startup.
A page generated from a JSP is also a resource. The page can call EJBs or COM resources to execute a transaction. 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 
.
Another type of organizational node is an application node represented by a green resource icon 
. This icon depicts a collection of resources that provide a specific set of services. Applications are considered organizational because they often consist of multiple, distributed components, such as an n-tier web application that may have resources on a web server, an application server, and a data server. 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 
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 
. A binding node is used to associate (or bind) a subset of the resource tree to a particular configuration.
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. Figure 5-2 shows how organizations, applications and resources are represented and bound to Security Service Modules in the Administration Console.
Some typical resources that you might want to secure, include:
The following topics provide more information:
A resource attribute is represented by the 
icon in the Administration Console. 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.
Attributes are inherited by child resources from their parent. If a resource explicitly sets the value for an attribute, the inherited value overrides the resource value.
A privilege is represented by the key 
icon in the Administration Console 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 5-3 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.
A privilege group is represented by the keys 
icon in the Administration Console 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 the policy. Figure 5-4 shows an example of how privilege groups and their associated privileges appear in the Administration Console.
The Identity 
icon represents your directories and user communities in the Administration Console. 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. The recommended approach is to use an Attribute Retriever, which can go directly to the data store, or multiple Attribute Retrievers if you need to access multiple data stores simultaneously for a unified view. You can also use AquaLogic Data Services Platform for data aggregation.
| Note: | Identity data are used to calculate roles used in your authorization policy and is not used for authentication purposes. Authentication is supported through your external repositories by configuring an authentication provider. |
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 5-5 shows how directories are represented in the Administration Console. In this example, there are two directories: ales and Employees. The employees directory shows the attributes that are stored for each member of the directory: zipcode, state, name, city and address. The zipcode and state attributes have default values set.
The number of directories you have depends on the level of granularity needed to separate your user community. You may want to have one global directory containing all users. In this case, you can populate a single directory using multiple external repositories. Or, you might want separate directories-one directory for customers, one for employees, and one for partners, where the method of authentication is different for each group. Having one directory requires a unique name for each user and group. If you are not able to guarantee this when you integrate your repositories, you should maintain separate directories.
The following topics provide more information about Identity:
A user is represented by the 
icon in the Administration Console 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. 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 5-6 shows an example of a user representation with identity attributes. In this example, userid1000 belongs to four groups and there are nine attributes associated with the user.
A group is represented by the 
icon in the Administration Console 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. All group names must be unique within a application domain.
Managing groups is more efficient than managing large numbers of users individually. By using groups, you do not need to define 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 5-7 shows how groups are represented in the Administration Console. In this illustration, the junior_trader group contains three group members, three user members, and one attribute (my_favorite_color).
Identity attributes are represented by the 
icon in the Administration Console (as shown in Figure 5-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 access control policies.
A role is represented by the 
icon in the Administration Console. A role is a dynamic alias used to associate users and groups to policy-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, based on how you distribute the policy. A role can also be delegated from one user to another user.
Granting a role to a user or a group confers the defined access privileges to that user or group, as long as the user or group is a member of the role. Multiple users or groups can be granted a single security role.
Authorization policy controls what actions a user can perform on a resource. Authorization policies are typically written to grant specific privileges upon resources to users within a given role under a defined set of conditions.
The following topics provide more information:
A role mapping policy is represented by the 
icon in the Administration Console and displays the policies that determine the membership for each role you have created, to which a user or group can be assigned. BEA recommends defining roles, and then assigning users and groups to those roles. A delegation policy assigns a role or privilege on a resource from one user or group (delegator) to another user or group (delegate). To delegate, the delegator must first have the role assigned to them. Role mapping policies are used to assign users or groups to membership in roles. The membership can be limited based on a number of items including the resource hierarchy, identity, contextual, and resource attributes. Roles may also be delegated from one user to another using delegation policies.
Authorization policies are represented by the icon in the Administration Console 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 can define privileges, resources, policy subjects (users, groups, and roles), constraints, and delegators. For ease of policy management, BEA recommends that authorization policies be written to grant privileges to roles, rather then granting them directly to users or groups. 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.
Role mapping policy reports are represented by the 
icon in the Administration Console Using this function you can create a role mapping policy inquiry and use it generate a report that you can use for analysis. Role mapping policy inquiries search for role-based, access-control policies written against specific resources that match specified characteristics exactly. 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 can do what to what resource?
Authorization policy reports are represented by the icon in the Administration Console. Using this function you can create an authorization policy inquiry and use it 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 the question, Who can do what to what resource?
Declarations are represented by the 
icon in the Administration Console. 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. There are four types of declarations:
Deployment is represented by the 
icon in the Administration Console.
Once you have designed your access control policies, you must deploy it before it can take effect in your environment. Before you deploy policy, choose the distribution point for the policy. 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 effected modules to make use of the new configuration; this means you must restart the Security Service Module component and your application.
The Deployment Status page allows you to gather information regarding policy and configuration deployments. The page shows if any components are out of sync with the central Administration Server.
|
