Administration Application Guide
|
 |
 |
|
|
 |
 |
This section provides information on the following topics:
The security role defines a set of capabilities granted to users and groups based on specific conditions. Like groups, security roles allow you to restrict access to resources for several users at once. By using security roles, you limit what the user can do. Security roles differ from groups as follows:
Granting a security 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 in the security role. For example, an administrator may define a security role called AppAdmin, which has write access to the resources of a particular web application. Any user or group granted the AppAdmin security role then has write access to that URL (Web) resource. Multiple users or groups can be granted a single security role and a user or group can belong to multiple roles.
At runtime, the Security Service compares users or groups against a role condition to determine whether they should be dynamically granted a security role. This process is referred to as role mapping, and occurs just prior to when the security service renders an access decision for a protected resource. An access decision is the component of an Authorization provider that determines whether a subject has permission to perform a given operation on a resource.
This dynamic mapping of security roles to users or groups provides a very important benefit: users or groups can be granted a security role based on business rules, or the context of the request. For example, a user may be allowed to be in a Manager security role only while the actual manager is away. Dynamically granting this security role means that you do not need to change or redeploy your application to allow for such a temporarily arrangement. You simply specify the hours between which the temporary manager should have special privileges. Further, you do not need to remember to revoke these special capabilities when the actual manager returns, as you would if you temporarily added the user to a management group.
An administration policy is provided with the product to protect the Administration Application and its resources. This policy defines what tasks each role is allowed to perform within the console, which resources are protected, and how. While one user may be able to perform any and all tasks, you may want to allow other users to perform only a subset of those tasks. You can customize the administration policy by changing or replacing the roles and rules to suit your business needs. You may add users to each role or you may create your own roles with a new set of capabilities. You can customize the Admin policy and modify it to suit your needs.
Because you may have several different levels of administration (for example one administrator might manage resources and another might manage identities), you probably want to assign various tasks to different individuals.
The following security roles are defined by the administration policy:
Two additional roles, Anonymous Role and Everyone Role are also included, however, these have minimal rules written against them. The sections that follow describe each role and its capabilities. The capabilities of each role are not hard coded; they are determined by the policy rules. The rule set may be modified or completely replaced to change the capabilities as needed. Additionally, new roles may be created to provide other combinations of capabilities.
A user of the Administration Application is assigned to one or more of these roles to determine what capabilities they have. The only role assignment provided in the default policy is the assignment of the user system to the Admin role.
Policy data is represented in the console using a specific proprietary format that requires the use of qualifiers. For additional information on qualifiers and naming of policy elements, see Securing Resources and Defining Policy Rules, in the BEA WebLogic Enterprise Security Policy Managers Guide.
Note: After you understand the Admin policy design, you can begin modifying it to suit your own needs, as described in Default Admin Policy.
The Admin role has complete control over a set of policy elements:
Anyone belonging to this role has all capabilities, except the ability to write deny rules. Although BEA discourages the use of deny rules, you can change the policy to allow this capability.
To view a list users and groups who belong to the Admin role, click Role, and then click Admin. The Roles pane displays the following information.
Figure 3-1 Roles Pane for Admin
The Roles pane lists the rules assigning users and groups to roles. In this example, the user system is granted the Admin role for the root nodes of the Administration Application, WLES and WLESRecovery>>console. The privileges you define in your administration policy typically represent actions that you grant or deny. You grant or deny privileges through security rules. Typically sets of privileges are granted to Roles, then Roles are granted to users and groups.
To view the policy rules associated with the Admin role, click Role, click Admin, and then click Policy Inquiry.
Figure 3-2 Policy Rules for Admin Role
The Policy Inquiry page lists each resource that the user is allowed to access and the privilege (for example, GET, POST, addMember, bind), that applies to that resource. Each entry in the resulting table shows the name of a Privilege (What action can the Admin take?), a Resource (What resource can the Admin access?), and any Policy Conditions that apply to the policy rule (What conditions apply to the rule?).
Notice the use of Policy Conditions; sys_user_q is a built-in system attribute defined as the current user in the system group: //user/wles/system/. For additional information on built-in system attributes, see "Securing Resources and Defining Policy Rules," in the BEA WebLogic Enterprise Security Policy Managers Guide.
A Resource is defined as it appears in the resource tree. For example, the resource referred to as policy>>WLES>>DefaultWebApp is represented in the console as follows:
Figure 3-3 Representation of the WLES Resource
Here, the DefaultWebApp is a child node bound to its parent: WLES. In turn, this node has one child resource node defined as url, which represents the URL of the default web application being protected.
The Deployer security role has more limited control over a set of policy elements:
No one is assigned to the Deployer role (as shown here). You may choose to add users to this role and modify the rules associated with it or you may create a new role that better suits your needs. To view the policy rules associated with this role, click Role, click Deployer, and then click Policy Inquiry.
The Operator security role has the following rights:
There are no users assigned to this role. You may choose to add users to this role and modify the rules associated with it or you may create a new role that better suits your needs.
The Monitor security role has the following rights:
This security role effectively provides read-only access to the Administration Console. There are no users assigned to this role. You may choose to add users to this role and modify the rules associated with it or you may create a new role that better suits your needs.
The Everyone security role is assigned to all authenticated and unauthenticated users (allusers). The Everyone role is limited to the following rights:
You can assign privileges to allow additional capabilities. You may choose to add users to this role and modify the rules associated with it or you may create a new role that better suits your needs.
The Anonymous role has no rights and no users are assigned to this role. This role typically contains all unauthenticated users and allows access to only unprotected resources.
Table 3-1 lists the resources protected by the Admin Policy with a description of each one. You can write rules based on these resources to control what privileges users have within the Administration Application. By default, the admin resources are all nested below the //app/policy/WLES organization node. These resources are organized into a hierarchy to make writing policy simpler.
Table 3-2 lists the privileges that apply to the security roles and describes each one. The view privilege is required to see the contents of an instance of a policy element, for example, to see the value of an attribute. The listAll privilege is needed to list all the instances of a particular type of policy element, for example, to see all the users in a directory. You may want to think of this as the difference between being able to open a file and to list a file in a directory. You can use these privileges in rules to control what operations administrators of the Administration Application may perform.
When the Administration Application performs an authorization check, contextual data is provided to allow for fine-grained protection of policy operations. For example, when creating a privilege, the name of the privilege is supplied as an attribute, enabling you to control access to a single unique privilege and to all privileges.
The following attributes are used by the Administration Application; additionally, you may use any of the standard built-in attributes which are always available during authorization.
|
The name of a data type, for example, a string, integer, date. |
||
|
Enumeration (resource_attribute, subject_attribute, dynamic_attribute) |
Specifies the type of policy element with which an attribute declaration is associated. |
|
|
Enumeration (resource_attribute, subject_attribute, dynamic_attribute) |
||
|
Generic attribute used to represent the value of an element. |
||
|
Generic attribute used to represent the value of an element as a list. |
||
|
Used in modification operations to represent the new default value of an attribute value. |
||
|
Used in modification operations to represent the new default value of a list attribute. |
||
|
The constraint of a rule; this is the portion between the `if' and `;' exclusive. |
||
|
A list of deleted engines.1 |
||
The following evaluation functions are provided to help you write custom administration policies. They may be used in the constraint portion of rules to limit the applicability of the rule based on contextual information.
Now that you have an understanding of the elements that make up the administration policy, it is important to understand when the administration system performs authorization queries and what contextual attribute data is supplied with that query. This is the data that you may reference when writing rules to protect the Administration Application.
Table 3-6 lists the name of each enumerated type used in the Admin policy.
Rules define capabilities that ultimately control what operations a user is allowed to perform within the Administration Application. The admin policy provided with the product defines a default set of capabilities.
Table 3-7 lists and describes the rules included in the default admin policy.
The default admin policy is intended to be customized to meet an individual customers needs. Because the dynamic roles may be granted contextually, you may make a user a member of a role within a limited scope. For example, you can make user Joe a member of the Admin role, but only over resources.
grant(//role/Admin, //app/policy/WLES/admin/Resource, //user/wles/Joe/) if true;
This allows Joe to act as an Administrator over resources, but does not give him rights to write policy.
To make your rule more explicit, you can let user Bob be an Administrator when modifying any policy element for a certain application. With an application with a resource rooted at //app/policy/PetStore, you can define the following rule.
grant(//role/Admin, //app/policy/WLES/admin, //user/wles/Bob/) if sys_defined(resource) and resource_is_child(resource, //app/policy/PetStore, no);
This allows Bob to act in the Admin role for any admin policy query involving the PetStore.
Now that you feel you understand the basic rules involved in constructing the Admin Policy, see see "Securing Resources and Defining Policy Rules," in the BEA WebLogic Enterprise Security Policy Managers Guide for additional information on how to implement rules.
|
|
|
