Protecting System Administration Operations

Many engineering teams divide administration responsibilities into distinct roles. Each project might give only one or two team members permission to deploy applications or modules, but allow all team members to view the server configuration. As described in Securing WebLogic Resources , WebLogic Server supports this division of responsibility by allowing administrators to secure WebLogic resources with security policies. Typically, these security policies are based on whether users or groups of users are granted a particular security role.

A server resource is a specific type of WebLogic resource that is related to WebLogic Server instances. This type of WebLogic resource includes operations that start, shut down, lock, or unlock servers, and is therefore the type of WebLogic resource with which most administrators interact. (For information about the other types of WebLogic resources, see Types of WebLogic Resources in Securing WebLogic Resources.) Like other types of WebLogic resources, a server resource is secured with security policies. However, because the configuration of a server is exposed through a set of MBeans, a server resource also has additional protections that affect how administrators access their operations.

 

 

Security Policies on Server Resources

A security policy is an association between a WebLogic resource and one or more users, groups, or security roles that is designed to protect the WebLogic resource against unauthorized access. A WebLogic resource has no protection until you create a security policy for it. WebLogic Server defines default security policies for WebLogic resources based on the default global role and default group associations shown in Table  9-1.

Table 9-1 Default Group Associations

Members of This Group	Are Granted This Global Role
Administrators	Admin
Deployers	Deployer
Operators	Operator
Monitors	Monitor

Notes: WebLogic Server grants these four default global roles to four default groups. By adding a user to one of these groups, the user is automatically granted the global role. When you use the Configuration Wizard to create a new WebLogic Server domain, the administrative user that you create is made a member of the Administrators group, and, therefore, is granted the Admin security role. The Deployers, Operators, and Monitors groups are initially empty.

All server resources inherit a default security policy that is based on both the Admin and Operator global roles. The Policy Statement list box in Figure  9-1 shows the default security policy for the server resource myserver (viewed by right-clicking on myserver in the navigation tree and selecting the Define Security Policy... option). Figure 9-1 Default Security Policy for the myserver Server

Note: For more detailed information about security policies, and instructions on how to create security policies for WebLogic resources, see Security Policies" in Securing WebLogic Resources.

While you can create your own global roles for securing server resources, only users granted the default global roles in Table  9-1 can view or change the configuration of a server. Table  9-2 provides a high-level description of the immutable privileges that users or groups granted these security roles are given when interacting with the interfaces described in Protected Public Interfaces.

Table 9-2 Default Global Roles and Their Privileges

Global Role	Privileges
Admin	View the server configuration, including the encrypted value of encrypted attributes. Modify the entire server configuration. Deploy applications, Webapp modules, EJB modules, Connector modules, Web Service modules, and startup and shutdown classes. Start, resume, and stop servers by default.
Deployer	View the server configuration, except for encrypted attributes. Deploy applications, Webapp modules, EJB modules, Connector modules, Web Service modules, and startup and shutdown classes.
Operator	View the server configuration, except for encrypted attributes. Start, resume, and stop servers by default.
Monitor	View the server configuration, except for encrypted attributes. Note: This security role effectively provides read-only access to the WebLogic Server console, weblogic.Admin utility and MBean APIs.

 

 

Overlapping Protections on MBeans

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). The ServerResource class is secured by a security policy, as described in Security Policies on Server Resources.

However, 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 ServerMBeanRuntime.start() operation. These MBeans are protected using one of the four default global roles shown in Table  9-2. (This protection is in addition to the security policy on the server resource.)

Therefore, when a user tries to change the attributes or invoke the operations of one of these MBeans, the WebLogic Security Service determines whether the user is granted one of the default global roles permitted to carry out the task. It then checks the security policy on the server resource (which also uses a global role ) to verify that the user meets the requirement defined by the security policy. In other words, a user must satisfy both security schemes for their request to be successful.

Figure  9-2 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 9-2 Overlapping Permissions for Server Resources

 

 

Maintaining a Consistent Security Scheme

The 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 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 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.

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

• Always giving the Admin global role access to a server resource.
• For a security policy on a server, using the Operator global role.
• For a security policy on a deployable resource (such as an application, EJB module, Webapp module, Connector module, or startup/shutdown class), using the Deployer global role.
• When creating a new global role, nesting your global role inside one of the default global roles to give users appropriate permissions.

Note: For step-by-step instructions on creating and modifying security policies, see Security Policies" in Securing WebLogic Resources.

 

 

Protected MBean Attributes and Operations

Table  9-3 lists the immutable privileges given to users who are granted the Admin default global role, for various MBeans related to server resources.

Table 9-3 MBean Privileges for the Admin Default Global Role

MBean	Attributes
BridgeDestinationCommonMBean	UserPassword
BridgeDestinationMBean	UserPassword
JDBCConnectionPoolMBean	Password, XAPassword
JDBCDataSourceFactoryMBean	Password
JMSBridgeDestinationMBean	UserPassword
NetworkChannelMBean	DefaultIIOPPassword
NodeManagerMBean	CertificatePassword
SecurityConfigurationMBean	Credential, EncryptedSecretKey, Salt
SecurityMBean	Salt, EncryptedSecretKey, InteropPassword
ServerMBean	SystemPassword,DefaultIIOPPassword, DefaultTGIOPPassword, CustomIdentityKeyStorePassPhrase, CustomTrustKeyStorePassPhrase, JavaStandardTrustKeyStorePassPhrase
ServerStartMBean	Password
SSLMBean	ServerPrivateKeyPassPhrase
WLECConnectionPoolMBean	UserPassword, ApplicationPassword

Notes: The MBeans shown in Table  9-3 are all in the weblogic.management.configuration package.

Table  9-4 lists the immutable privileges given to users who are granted the Admin and Deployer default global roles, for various server objects and operations.

Table 9-4 Privileges for the Admin and Deployer Default Global Roles

Server Objects	Operations
Application, ApplicationConfig	All
ConnectorComponent, ConnectorComponentConfig	All
DeployerRuntime, DeploymentTaskRuntime	All
EJBComponent, EJBComponentConfig	All
WebAppComponent, WebAppComponentConfig	All
WebServiceComponent, WebServiceComponentConfig	All
WebServer, WebServerConfig	All
JDBCConnectionPool, JDBCConnectionPoolConfig	All
JDBCDataSourceFactory, JDBCDataSourceFactoryConfig	All
JDBCMultiPool, JDBCMultipoolConfig	All
JDBCDataSource, JDBCDataSourceConfig	All
JDBCTxDataSource, JDBCTxDataSourceConfig	All
JDBCPoolComponent, JDBCPoolComponentConfig	All
JMSBridgeDestination, JMSBridgeDestinationConfig	All
JMSConnectionConsumer, JMSConnectionConsumerConfig	All
JMSConnectionFactory, JMSConnectionFactoryConfig	All
JMSDestination, JMSDestinationConfig	All
JMSDistributedDestination, JMSDistributedDestinationConfig	All
JMSDistributedDestinationMember, JMSDistributedDestinationMemberConfig	All
JMSDistributedTopic, JMSDistributedTopicConfig	All
JMSDistributedTopicMember, JMSDistributedTopicMemberConfig	All
JMSDistributedQueue, JMSDistributedQueueConfig	All
JMSDistributedQueueMember, JMSDistributedQueueMemberConfig	All
JMSFileStore, JMSFileStoreConfig	All
JMSDestinationKey, JMSDestinationKeyConfig	All
JMSServer, JMSServerConfig	All
JMSStore, JMSStoreConfig	All
JMSSessionPool, JMSSessionPoolConfig	All
JMSTemplate, JMSTemplateConfig	All
JMSQueue, JMSQueueConfig	All
JMSTopic, JMSTopicConfig	All
JMSJDBCStore, JMSJDBCStoreConfig	All
WTCServer, WTCServerConfig	All
WTCBridgeGlobal, WTCBridgeGlobalConfig	All
WTCResources, WTCResourcesConfig	All
WTCExport, WTCExportConfig	All
WTCImport, WTCImportConfig	All
WTCLocalTuxDom, WTCLocalTuxDomConfig	All
WTCRemoteTuxDom, WTCRemoteTuxDomConfig	All
WTCPassword, WTCPasswordConfig	All
WTCtBridgeGlobal, WTCtBridgeGlobalConfig	All
WTCtBridgeRedirect, WTCtBridgeRedirectConfig	All
EJBDescriptor, ConnectorDescriptor, WebDescriptor	All
Server	addDeployment, lookupServerLifeCycleRuntime, lookupServerRuntime, removeDeployment, sendNotification
ServerConfig	addDeployment, lookupServerLifeCycleRuntime, removeDeployment, sendNotification

Table  9-5 lists the immutable privileges given to users who are granted the Admin and Monitor default global roles, for various server objects and operations.

Table 9-5 Privileges for the Admin and Monitor Default Global Roles

Server Objects	Operations
Machine	lookupNodeManagerRuntime
NodeManagerRuntime	getStateForAll, register
Server	lookupServerLifeCycleRuntime, lookupServerRuntime

Table  9-6 lists the immutable privileges given to users who are granted the Admin and Operator default global roles, for various server objects and operations.

Table 9-6 Privileges for the Admin or Operator Default Global Roles

Server Objects	Operations
ServerLifeCycleRuntime	All
ServerLifeCycleTaskRuntime	All
ServerStart	All
Server	ExpectedToRun, lookupServerLifeCycleRuntime, lookupServerRuntime, sendNotification, start, suspend
ServerConfig	ExpectedToRun, lookupServerLifeCycleRuntime, sendNotification
ServerRuntime	forceShutdown, resume, shutdown, start, stop

 

 

Protected Public Interfaces

The WebLogic Server 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  9-1. Therefore, to use the console, a user must belong to one of these default groups or be granted one of these global roles. Additionally, administrative functions that require interaction with MBeans are secured using the MBean protections described in Overlapping Protections on MBeans. Therefore, a user of the following protected public interfaces must satisfy both security schemes:

• The WebLogic Server console - The WebLogic Security Service verifies whether a particular user can access the 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 Security Role-Based console Views and the console Online Help.

• The weblogic.Admin command - The WebLogic Security Service verifies whether a particular user has permission 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 Protected MBean Attributes and Operations and 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 retrieve the MBeanHome interface. 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 Protected MBean Attributes and Operations and Programming WebLogic JMX Services.

 

 

Security Role-Based console Views

The WebLogic Server console allows users to edit configurations or to perform other operations based on the security role they are granted. If the security role does not permit editing of configuration data, for example, the data is displayed in the console but is not editable. If the user attempts to perform a control operation that is not permitted, such as starting or stopping servers, the console displays an Access Denied error.

In this release of WebLogic Server, users in the Admin default global role can perform any function using the console. The other default global roles (Deployer, Monitor, and Operator) primarily have read-only permissions, except for functions specific to their role.

Note: If a user does not belong to one of the four default groups described in Table  9-1, that user cannot log in to the console.

Table  9-7 lists the default global roles and describes the view of the console for users granted these security roles.

Table 9-7 Security Role-Based console Views

Default Global Role	console View
Admin	Everything is visible, including all: Apply buttons (when viewing the configuration of an existing entity ) Create a new..." links Clone and Delete icons (part of table views) Create, Clone, and Delete operations in the navigation tree Additionally, user in the Admin security role can view security information. More specifically, they can see the Security and CompatibilitySecurity nodes in the navigation tree, and can right-click on WebLogic resources to define a security policy, scoped role, or credential mapping.
Deployer	Everything is visible except: Apply buttons (typically appear when viewing the configuration of an existing entity ) Clone and Delete icons for non-deployable objects (typically part of table views) Create a new..." links for non-deployable objects Create, Clone, and Delete operations for non-deployable objects (typically part of the navigation tree) Note: Deployable objects include applications, Webapp modules, EJB modules, Connector modules, JDBC connection pools, JDBC data sources, JDBC MultiPools, JDBC data source factories, JMS servers, and WTC Services. Applications to not have Clone icons. Additionally, users in the Deployer security role can edit the Load Order field of an application.
Monitor and Operator	Everything is visible except: Apply buttons (typically appear when viewing the configuration of an existing entity Clone and Delete icons (typically part of table views) Create a new..." links Create, Clone, and Delete operations (typically part of the navigation tree) In addition, all fields are read-only for users in the Monitor and Operator security roles.

Notes: For fields that are read-only and do not have an assigned value, the text "(No Value Assigned)" is shown. No user, regardless of the security role they are granted, can view the non-encrypted version of an encrypted attribute in the console.

 

 

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, 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 MBean security scheme, is the authorizer. For example, a user in the Operator 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.

 

 

Permissions for Using the Node Manager

The Node Manager uses both MBeans and 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.

 

 

Shutting Down a WebLogic Server Instance

Shutting down a WebLogic Server instance also involves both MBeans and 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 security scheme). 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.