Administration Application Guide
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.
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
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 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,
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.
The Policy Inquiry page lists each resource that the user is allowed to access and the privilege (for example,
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.
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.
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.
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.
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.
View the contents of a policy element, including identities (identity directories, users, groups, identity attributes), resources and their attributes, configuration data and their bindings, privileges and privilege groups.
Delete a policy element, including identities (identity directories, users, groups, identity attributes), resources and their attributes, configuration data and their bindings, and privileges and privilege groups.
Delete an element and its sub-elements (no permission check is made on sub-elements), including identities (identity directories, users, groups, identity attributes), resources and their attributes, configuration data and their bindings, and privileges and privilege groups.
Rename a policy element, including identities (identity directories, users, groups, identity attributes), resources and their attributes, configuration data and their bindings, and privileges and privilege groups.
Modify the contents of a policy element, including identities (identity directories, users, groups, identity attributes), resources and their attributes, configuration data and their bindings, and privileges and privilege groups.
Copy a policy element, including identities (identity directories, users, groups, identity attributes), resources and their attributes, configuration data and their bindings, and privileges and privilege groups.
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.
A list of deleted engines.1
1. The term engine refers to an ASI Authorization and ASI Role Mapper provider that are configured to operate in conjunction with one another. This combination of providers are configured to manage your authorization policy.
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.
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.
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.