Introduction to WebLogic Enterprise Security
|
 |
 |
|
|
 |
 |
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 security policies. A policy is composed of a set of rules, modeled on your organizational business requirements that state who has access to which resources.
The rules that define your security 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 security policies. The following sections describe security management concepts and how you implement security using the Administration Console:
Figure 4-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.
Figure 4-1 Administration Console Resource Representation
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 4-1 shows how each provider type is represented in the Administration Console.
Table 4-1 Security Providers and their Representations
To learn more about security providers and their services, see BEA WebLogic Enterprise Security Architecture. For information on how to develop custom security providers, see Developing Security Providers for WebLogic Enterprise Security.
A configuration is a named collection of elements and security services over which a common and consistent set of policies (or rules) 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. A resource has no protection until you create and apply a policy. Each Security Service Module has a Configuration ID associated with it that defines the security providers, policy, and settings for that Security Service Module.
In Figure 4-2, two Security Service Modules are installed on each of two machines, with all modules and configurations managed centrally by one Administration Application. The Service Control Manager provides configuration to each Security Service Module as needed, any time a change in configuration is required. Notice that Security Service Modules on the left use the same set of providers and share a set of policies, resources, and policy domains. The Security Service Modules on the right use a similar set of policies, resources, and policy domains, but use a different set of providers.
Figure 4-2 Policies and Security Configuration
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. 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 4-3. The resources shown here represent the administration services and policy data elements that are accessible to the Administration Application 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 4-3 shows how organizations, applications and resources are represented and bound to Security Service Modules in the Administration Console.
Figure 4-3 Organizations, Applications, and Resources form your Security Configuration
Some typical resources that you might want to secure, include:
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 4-4 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.
Figure 4-4 Privilege Representation in the Administration Console
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 a filters when constructing rules, although they cannot appear directly in the rule. Figure 4-5 shows an example of how privilege groups and their associated privileges appear in the Administration Console.
Figure 4-5 Privilege Group Representation in the Administration Console
The Identity 
icon represents your directories and user communities in the Administration Console. Although BEA WebLogic 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.
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 4-6 shows how directories are represented in the Administration Console. In this example, there are two directories: wles and Employees. The Employees directory shows the attributes that are stored for each member of the directory: zipcode, state, name, city and address. The state attribute has a default value set to MA (Massachusetts).
Figure 4-6 Directory Representation in the Administration Console
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. For information on integrating with external identity repositories, see the Administration Application Installation Guide.
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 4-7 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.
Figure 4-7 User Representation in the Administration Console
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 policy 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 rules 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 4-8 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).
Figure 4-8 Group Representation in the Administration Console
Identity attributes are represented by the 
icon in the Administration Console (as shown in Figure 4-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 rules to set limits for that user. Attributes provide a very powerful way to refer to users and groups indirectly in rules, which results in a more dynamic and versatile policy.
A roles 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.
A role policy is represented by the 
icon in the Administration Console and displays the rules 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 rule 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 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, identity, contextual, and resource attributes. Roles may also be delegated from one user to another using role delegation rules.
Authorization policy controls what actions a user can perform on a resource as defined by a set of rules. The authorization rules are typically written to grant specific privileges upon resources to users within a given role under a defined set of conditions. Figure 4-9 shows how the process of authorizing a user involves both computing the user role membership and then applying the authorization policy.
Figure 4-9 Role-based Authorization Policy
A policy rule is represented by the blue check mark 
icon in the Administration Console. A policy rule defines the privileges, resources, subjects (users, groups, and roles), and constraints that apply to the rule. BEA recommends that authorization rules be written to grant privileges to roles, rather then granting them directly to users or groups.
A policy rule may also be used to assign a privilege on a resource from one user (delegator) to another user or group (delegate); this is referred to as a delegate rule.
A policy inquiry is represented by the
icon, in the Administration Console and allows you to analyze your authorization policy before distributing it. You can generate a query by providing a value for any policy element (privilege, user or group, role or resource). If you want more specific results, you may combine two or more policy elements.
A policy inquiry is a type of policy analysis that allows you to ask questions about how a policy responds to specific access requests. Policy inquiry performs a special type of rule search that takes into account role inheritance, resource hierarchies, and user to group mappings when determining the results. As with searches, there are two main classes of inquiries: grant and deny. Grant inquiries are more common. Grant inquiries ask what rules contain access rights that directly or indirectly match input values. Deny inquiries ask what rules deny access rights that directly or indirectly match input values.
A policy verification is represented by the
icon in the Administration Console. You can cross check a policy using policy verification or you can search the list of policies to determine what privileges users and groups have over the selected resources. A policy verification allows you to find users whose rights were intended to be mutually exclusive.
At first, inquiries and verifications look very similar. However, an inquiry asks about specific users, actions, and applications. In verification, you are asking which users can perform mutually exclusive activities. With verifications you are looking for conflicting entitlements in individual user's security policies. With policy verifications, you are asking who is entitled to do one of two different actions. The results contain a list of those users who can do both, so you can verify whether your policy contains access rights for a single user that could pose a security risk.
Note: Policy inquiry and verification do not take role membership into account when analyzing the policy.
A declaration is represented by the 
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 rules, 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 and tested your security policy and configuration, you need to deploy it before the policy and configuration take effect in your environment. Before you distribute policy, you 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 Application.
Now that you understand the basic building blocks involved in security configuration and policy management, you can begin modeling your policy. The Policy Managers Guide provides some guidelines as to how to begin.
|
|
|
