Administration Guide

Protecting System Administration Operations

To leverage individual skills, many Web development teams divide system administration responsibilities into distinct roles. Each project might give only one or two team members permission to deploy components, but allow all team members to view the WebLogic Server configuration. WebLogic Server supports this role-based development by providing global roles that determine access privileges for system administration operations: Anonymous, Admin, Deployer, Operator, and Monitor.

The following sections describe security roles and system administration operations:

• Operations Available to Each Role

• Protected User Interfaces

• Permissions for Starting and Shutting Down Servers

Note: These role-based permissions replace access control lists (ACLs) for securing WebLogic Server MBeans, which were used before Release 7.0.

Operations Available to Each Role

Table 3-1 describes the four global roles that WebLogic Server uses to determine access privileges for system administration operations, and the permissions granted to each role.

No user, regardless of role membership, can view the non-encrypted version of an encrypted attribute.

Note: If you are working directly with WebLogic Server MBeans and want more detailed information about the global roles and their privileges than is shown in Table 3-1, see "Protected MBean Attributes and Operations" in Securing WebLogic Resources.

You can add to the default global roles by creating your own security roles (global or scoped) as described in "Ways to Create Security Roles in the Administration Console" in Securing WebLogic Resources.

Default Group Associations

By default, WebLogic Server grants four of the default global roles to four of the default groups. By adding a user to one of these groups, the user is automatically granted the global role. These default group associations are shown in Table 3-2.

For information on creating users and assigning them to groups, refer to Creating Users and Adding Users to Groups in the Securing WebLogic Resources guide.

Protected User Interfaces

The WebLogic Server Administration Console, the weblogic.Admin command, and MBean APIs are secured using the default security policies, which are based on the default global roles and default groups described in Table 3-1and Table 3-2. Therefore, to use the Administration Console, a user must belong to one of these default groups or be granted one of these global roles. Additionally, administrative operations that require interaction with MBeans are secured using the MBean protections described in "Protected MBean Attributes and Operations" in Securing WebLogic Resources. Therefore, interaction with the following protected public interfaces typically must satisfy both security schemes.

• The WebLogic Server Administration Console—The WebLogic Security Service verifies whether a particular user can access the Administration Console when the user attempts to log in. If a user attempts to invoke an operation for which they do not have access, they see an Access Denied error.

  For information about using this public interface, see the Administration Console Online Help.

• The weblogic.Admin command—The WebLogic Security Service verifies whether a particular user has permission to execute a command when the user attempts to invoke the command. If a user attempts to invoke an operation for which they do not have access, WebLogic Server throws a weblogic.management.NoAccessRuntimeException, which developers can explicitly catch in their programs. The server sends this exception to its log file, but you can also configure the server to send exceptions to standard out.

  For information about using this public interface, see "weblogic.Admin Command-Line Reference" in the WebLogic Server Command Line Reference.

  Note: The weblogic.Admin command is a convenience utility that abstracts the interaction with the MBean APIs (described below). Therefore, for any administrative task you can perform using the weblogic.Admin command, you can also choose to write yourself using the MBean APIs.

• MBean APIs—The WebLogic Security Service verifies whether a particular user has permission to access the API when the user attempts to perform an operation on the MBean. If a user attempts to invoke an operation for which they do not have access, WebLogic Server throws a weblogic.management.NoAccessRuntimeException, which developers can explicitly catch in their programs. The server sends this exception to its log file, but you can also configure the server to send exceptions to standard out.

  For information about using these APIs, see Programming WebLogic Management Services with JMX.

Layered Security Scheme for Server Resources

The following sections provide more information about the layered security scheme for Server resources:

• Security Policies for Server Resources

• MBean Protections

• How the WebLogic Security Service Verifies Layered Protections

• Example

• Maintaining a Consistent Security Scheme

Security Policies for Server Resources

Like other types of WebLogic resources, a Server resource is secured with security policies using the WebLogic Server Administration Console.

More specifically, all server resources inherit a default security policy that is based on the Admin and Operator default global security roles. As described in Operations Available to Each Role, the Admin and Operator global roles are given specific privileges that are required in order for administrators to interact with administrative interfaces like the Administration Console or the weblogic.Admin command. These default global roles are based on the default groups (described in Default Group Associations). Therefore, administrators who need access to Server resources need to be members of either the Administrators or Operators default groups.

Note: Because WebLogic Server grants the four default global roles to four default groups, adding a user to one of these groups automatically grants the user the global role.

Warning: Do not modify the default security policies for Server resources to make them more restrictive. Eliminating some of the existing security roles might negatively impact the functioning of WebLogic Server. However, if you like, you can make the default security policies more inclusive (for example, by adding new security roles).

MBean Protections

Each type of WebLogic resource (including a Server resource) exposes a set of its operations through its own implementation of the weblogic.security.spi.Resource interface (the weblogic.security.service.ServerResource class for Server resources). Therefore, the ServerResource class is the entity that is actually secured by the security policy described in Security Policies for Server Resources.

In WebLogic Server, the configuration of a Server resource is exposed through a set of MBeans. As such, the actions that the ServerResource class protects correspond to underlying MBean attributes and operations. For example, the Resource interface's start() method maps directly to the start operation of the ServerRuntime MBean.

The MBeans that expose the configuration of a Server resource are protected using one of the four default global roles. This protection is in addition to the security policy on the Server resource and is currently an unmodifiable part of the WebLogic Security Service. Therefore, while you can create your own global roles for securing Server resources, only users granted one of default global roles can view or change the configuration of a server.

How the WebLogic Security Service Verifies Layered Protections

When an administrator tries to interact with a Server resource, the WebLogic Security Service:

• Determines whether the user is granted one of the default global roles permitted to change the attributes or invoke the operations of the MBean.

• Checks the default security policy for the Server resource to verify that the user meets the requirement defined by that security scheme.

Therefore, a user must satisfy both security schemes for their request to be successful. Figure 3-1 provides a visual representation of how a security policy on the Server resource interacts with the security role-based protections on the underlying MBeans.

Figure 3-1 Layered Protections for Server Resources

Because the privileges given by the MBean protections are immutable, it is necessary to maintain security policies in a way that ensures consistency. (For more information, see Maintaining a Consistent Security Scheme.)

Example

This example illustrates how one Server resource is protected by the layered security scheme.

An administrator with the user name JDoe wants to start the server called myserver. This administrative user (JDoe) is a member of the default group Administrators, which by default is granted the Admin global security role. This user-to-group and group-to-security role configuration was set up using the WebLogic Server Administration Console, as described in other sections of this guide.

Part 1: MBean Protections

Because starting a server requires interactions with various MBeans, and because MBean protections are an immutable part of the WebLogic Security Service, a user wanting to perform such an operation must be in the Admin or Operator default global roles. For example, access to the Server and ServerRuntime MBeans (MBeans with start operations) is a privilege given only to users in these default security roles. Because the administrative user JDoe is a member of the default group Administrators, he is also granted the Admin global security role, and therefore fulfills the first part of the dual security scheme for Server resources.

Part 2: Security Policy on the Server Resource

As the Policy Statement list box in Figure 3-2 shows, the default security policy for myserver (viewed by right-clicking on myserver in the navigation tree and selecting the Define Security Policy... option) allows users granted the Admin or Operator global roles to interact with this Server resource. Because the administrative user JDoe is a member of the default group Administrators, he is also granted the Admin global security role, and therefore fulfills the second part of the layered security scheme for Server resources.

Figure 3-2 Default Security Policy for the myserver Server

Note: Had the administrative user JDoe been a member of the Operators group (and therefore granted the Operator default global role), he would have still fulfilled both parts of the dual security scheme.

Maintaining a Consistent Security Scheme

WebLogic Server's default configuration of groups, global roles, security policies on Server resources, and MBean protections work together to create a consistent security scheme. You can, however, make modifications that limit access in ways that you do not intend. You must be sure that any modifications you make to the default security settings do not prevent a user from being authorized by both the MBean protections and the security policy on the Server resource.

For example, if you use the WebLogic Server Administration Console to add a user to the Operator global role, but fail to use the Operator global role in the security policy defined for a Server resource, the user can call MBean operations that are used in the startup and shutdown sequence, but cannot use any server-resource operations to start or stop a server. Similarly, if you use the Administration Console to remove the Operator global role from a security policy on the Server resource, a user granted the Operator global role can still call MBean operations but cannot call the Server resource. This result occurs because MBean protections for the default global roles are part of the WebLogic Security Service and are currently unmodifiable.

To keep MBean protections synchronized with security policies, consider taking the following actions when you create or modify a security policy:

• Always give the Admin global role access to a Server resource.

• For a security policy on a server, use the Operator global role.

  Note: Failure to use the Operator global role or a security role nested within this default global role may result in problems with the WebLogic Security Service.

• For a security policy on a deployable resource (such as an application, EJB module, Web application module, Connector module, or startup/shutdown class), use the Deployer global role.

Permissions for Starting and Shutting Down Servers

WebLogic Server provides two ways to start and shut down WebLogic Server instances (servers): the weblogic.Server command and the Node Manager. Because the underlying components for the weblogic.Server command and the Node Manager are different, the two commands use different authorization methods.

The following sections provide more information about the permissions for starting and shutting down servers:

• Permissions for Using the weblogic.Server Command

• Permissions for Using the Node Manager

• Shutting Down a WebLogic Server Instance

Permissions for Using the weblogic.Server Command

The weblogic.Server command, which starts a WebLogic Server instance, calls methods that are protected by a security policy on the Server resource. To use this command, you must satisfy the requirements of the security policy on the Server resource.

Some weblogic.Server arguments set attributes for MBeans. However, because these arguments modify an MBean before the server is in the RUNNING state, the security policy on the Server resource, not the protection on the MBean, is the authorizer. For example, a user in the Operator global role can use the -Dweblogic.ListenPort argument to change a server's default listen port, but once the WebLogic Server instance is running, this user cannot change the listen port value.

For more information about weblogic.Server, see Using the weblogic.Server Command.

Permissions for Using the Node Manager

The Node Manager uses both MBeans and the security policy on the Server resource to start a remote server.

If you have configured a Node Manager on the host machine of a remote WebLogic Server instance, by default a user in the Admin or Operator global role can use the Node Manager to start the remote server.

For information about the Node Manager, refer to Managing Server Availability with Node Manager in the Creating and Configuring WebLogic Server Domains Guide.

Shutting Down a WebLogic Server Instance

Shutting down a WebLogic Server instance also involves both MBeans and the security policy on the Server resource. When a user issues a shutdown command, the server first determines whether that user is granted the Admin or Operator global role (per the MBean protection). Then, after the MBean operations run, the server determines whether the security policy on the Server resource authorizes the user to shut down the server.