Securing WebLogic Resources

Types of WebLogic Resources

A WebLogic resource is an object that the WebLogic Security Service creates to represent an underlying WebLogic Server entity and to determine who can access the entity. You create a security policy to specify which users, groups, or roles can access a resource under a set of conditions.

The following sections describe the types of resources that you can secure using the WebLogic Server Administration Console:

For information about APIs for WebLogic resources, see the weblogic.security.service package in the WebLogic Server API Reference.

Administrative Resources

Administrative resources determine who can complete such tasks as uploading files (used during deployment), viewing the domain and server logs, unlocking users who have been locked out of their accounts, and changing the configuration of servers, clusters, machines, and other components that are defined in the domain's configuration document (config.xml).

For many of these tasks, users must first be authorized by an additional security layer called the MBean security layer (see Figure 3-1).

Figure 3-1 Administrative Resource and MBean Security Layers Overlap

Administrative Resource and MBean Security Layers Overlap

The following sections describe the scheme for securing administrative activity in a domain:

MBean Security Layer

WebLogic Server uses managed beans (MBeans) in the implementation of its management system. Almost all administrative tasks require you to invoke an MBean operation or modify an MBean attribute using a Java Management Extensions (JMX) client. For example, the Administration Console is a JMX client. If you use it to change the value of a server's listen port, the Administration Console changes the value of an MBean attribute. The WebLogic Scripting Tool is also a JMX client. For more information, see Understanding WebLogic Server MBeans in Developing Custom Management Utilities with JMX.

To secure access to its MBeans, WebLogic Server requires JMX clients to be in one of the four default global roles: Anonymous, Admin, Deployer, Operator (see Default Global Roles). In most cases, only the Admin role can modify MBean attributes, though there are exceptions. To see a detailed description of which roles can modify WebLogic Server MBeans, see Security Roles for MBeans in the WebLogic Server MBean Reference. The security requirements for MBeans are immutable; you cannot change which roles can invoke MBean operations or change attributes.

When a JMX client attempts to invoke an operation or change an attribute that is also secured by an administrative resource, the client must also satisfy the policies defined in an administrative resource (see Figure 3-2).

Figure 3-2 MBean Security Layer Checks with Security Service When Needed

MBean Security Layer Checks with Security Service When Needed

Administrative Resource Layer

Table 3-1 describes the administrative activities that an administrative resource protects. Some of the protections overlap with the protections in the MBean security layer. For these overlaps, the default policies in the administrative resource simply duplicate the protections in the MBean security layer.

Table 3-1 Activities And Default Policies For Administrative Resource

Administrative Activities	Default Policy Allows These Roles	Overlap with MBean Security?
Upload files for deployment.	`Admin, Deployer`	No
Control access to these methods in the file download servlet: `ALL methods` `wl_component_request` `wl_ear_resource_request` `ear_request` `wl_xml_entity_request` `wl_jsp_refresh_request` `file` `wl_init_replica_request` `wl_file_realm_request` `wl_managed_server_independence_request` Note: The file download servlet is used internally by WebLogic Server. BEA recommends that you do not modify the default policies for any of its methods. They are listed here only for completeness.	`Admin, Operator`	No
View domain and server logs through the Administration Console.	`Admin, Deployer, Operator, Monitor`	Yes
Enable applications to use identity assertion. The default policy for this activity specifies that an application must supply credentials for a user who is in the `Admin` role before it can successfully invoke the `Authentication.assertIdentity()` API. See `weblogic.security.services.Authentication` in the WebLogic Server API Reference.	`Admin`	No
Unlock users who have been locked out of their accounts.	`Admin`	Yes
Change the configuration of an active domain. Note: BEA recommends that you not add or remove roles for this policy. Modifying this policy could result in inconsistencies between the Administration resource security layer and the MBean security layer. If you need to change the default settings, modify the definition of the roles.	`Admin, Deployer, Operator, Monitor`	Yes

Maintaining a Consistent Security Scheme

The MBean security layer and the default configuration of groups, global roles, and security policies on Administrative and Server resources work together to create a consistent security scheme. You can, however, make modifications to that limit access in ways that you do not intend. Make sure that any modifications you make to the default security settings do not prevent a user from being authorized by both the MBean security layer and the policies on the Administrative and Server resources.

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

Always include the Admin and Operator global roles in policies for Server resources.

Failure to use the Operator global role or a security role nested within this default global role may result in inconsistent behavior by the WebLogic Security Service.

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

Application Resources

An Application resource is a type of WebLogic resource that represents an enterprise application packaged as an EAR (Enterprise Archive). Similar to the Web application resource (see Web Application Resources) the hierarchy of an application resource is a mechanism for containment, rather than a type hierarchy. You secure an Application resource when you want to protect multiple WebLogic resources that constitute the EAR; for example, Web application, EJB, and Web Service resources. In other words, securing an enterprise application causes all WebLogic resources within that application to inherit its security configuration.

You can also secure, on an individual basis, the WebLogic resources that constitute an EAR. Securing a resource by both means causes the individual security configuration to override the security configuration inherited from the Enterprise Application for that WebLogic resource.

COM Resources

WebLogic jCOM is a software bridge that allows bidirectional access between Java/J2EE objects deployed in WebLogic Server, and Microsoft ActiveX components available within the Microsoft Office family of products, Visual Basic and C++ objects, and other Component Object Model/Distributed Component Object Model (COM/DCOM) environments.

A COM resource is a specific type of WebLogic resource that is designed as a program component object according to Microsoft's framework. To secure COM components accessed through BEA's bi-directional COM-Java (jCOM) bridging tool, you create security policies and security roles for packages containing multiple COM classes, or for individual COM classes.

For related information, see the Configuring Access Control section of Programming WebLogic jCOM.

Enterprise Information Systems (EIS) Resources

An EIS resource is a system-level software driver used by an application server, such as WebLogic Server, to connect to an Enterprise Information System. BEA supports resource adapters developed by EIS vendors and third-party application developers. Resource adapters. can be deployed in any application server supporting the applicable Sun Microsystems J2EE Platform Specification. Resource Adapters contain the Java code, and if necessary, the native components required to interact with the EIS.

To secure access to an EIS, create security policies and security roles for all resource adapters as a group, or for individual adapters.

For related information, see the Security section of Programming WebLogic Resource Adapters.

EJB Resources

An EJB (Enterprise JavaBean) resource is a specific type of WebLogic resource that is related to EJBs. To secure EJBs, you create security policies and security roles for EJB deployment modules, individual EJBs, or for individual methods on an EJB.

Because the J2EE platform standardizes EJB security in deployment descriptors, WebLogic Server integrates this standard mechanism with its Security Service to give you a choice of techniques for securing EJB resources. For more information, see Options for Securing Web Application and EJB Resources.

Java DataBase Connectivity (JDBC) Resources

A Java DataBase Connectivity (JDBC) resource is a specific type of WebLogic resource that is related to JDBC. You can secure JDBC resources that are deployed either as a service or an application. To secure JDBC database access, you can create security policies and security roles for all data sources as a group, individual data sources, and multi data sources.

JDBC Operations

When you secure an individual data source, you can choose whether to protect JDBC operations using one or more of the following administrator methods:

admin—The following methods on the JDBCDataSourceRuntimeMBean are invoked as admin operations: clearStatementCache, suspend, forceSuspend, resume, shutdown, forceShutdown, getProperties, and poolExists.
reserve—Applications reserve a connection in the data source by looking up the data source and then calling getConnection.

Note: Giving a user the reserve permission enables them to execute vendor-specific operations. Depending on the database vendor, some of these operations may have database security implications.

shrink—Shrinks the number of connections in the data source to the maximum of the currently reserved connections or to the initial size.
reset—Resets the data source connections by shutting down and re-establishing all physical database connections. This also clears the statement cache for each connection. You can only reset data source connections that are running normally.
All—An individual data source is protected by the union of the Admin, reserve, shrink, and reset administrator methods.

Note: If a security policy controls access to connections in a multi data source, access checks are performed at both levels of the JDBC resource hierarchy (once at the multi data source level, and again at the individual data source level). As with all types of WebLogic resources, this double-checking ensures that the most restrictive security policy controls access.

Note: If you use an Oracle database, you can also control access to JDBC resources using an Oracle Virtual Private Database (VPD). For more information, see Programming with Oracle Private Virtual Databases in Using Third-Party Drivers with WebLogic Server.

Java Messaging Service (JMS) Resources

A Java Messaging Service (JMS) resource is a specific type of WebLogic resource that is related to JMS. You can secure JMS resources that are deployed either as a service or an application. To secure JMS destinations, you create security policies and security roles for all destinations (JMS queues and JMS topics) as a group, or an individual destination (JMS queue or JMS topic) on a JMS server.

JMS Operations

When you secure a particular destination on a JMS server, you can protect operations on the destination. By default, destinations are not protected. This means that any valid user for a WebLogic server instance can send, receive, and browse messages on a destination. Only users defined by the Policy Condition can access control of the destination. Valid protection operations are:

send—Required to send a message to a queue or a topic. This includes calls to the MessageProducer.send(), QueueSender.send(), and TopicPublisher.publish() methods, as well as the Messaging Bridge.
receive—Required to create a consumer on a queue or a topic. This includes calls to the Session.createConsumer(), Session.createDurableSubscriber(), QueueSession.createReceiver(), TopicSession.createSubscriber(), TopicSession.createDurableSubscriber(), Connection.createConnectionConsumer(), Connection.createDurableConnectionConsumer(), QueueConnection.createConnectionConsumer(), TopicConnection.createConnectionConsumer(), and TopicConnection.createDurableConnectionConsumer() methods, as well as the Messaging Bridge and message-driven beans.
browse—Required to view the messages on a queue using the QueueBrowser interface.
ALL—Required to send, receive, and browse methods on a destination.

To protect operations for a destinations, do one of the following when creating Policy Conditions:

Select ALL Methods

To secure a resource for send, receive, and browse methods on a destination:

On the Security > Policies tab, select ALL from the Methods drop-down box.

Note: You may need to update the Providers and Policy Conditions on this page. See "Security Policies" in Securing WebLogic Resources.

Click Save.

You should select the ALL method when you want to create a policy condition where users have access to the send, receive, and browse methods for a destination. You cannot mix ALL methods with individual methods when creating Policy Condition. If you mix ALL method protection with individual methods protection when creating your Policy Condition, users associated with ALL methods are ignored when the Policy Condition is created.

Select Individual Methods

To individually secure a resource for send, receive, or browse for a destination:

On the Security > Policies tab, select send, receive, or browse from the Methods drop-down box.

Note: You may need to update the Providers and Policy Conditions on this page. See "Security Policies" in Securing WebLogic Resources.

Click Save.

You should select the send, receive, or browse methods when you want to create a policy condition where you individually associate send, receive, or browse methods for a destination. You cannot mix ALL methods with individual methods when creating Policy Condition. If you mix ALL method protection with individual methods protection when creating your Policy Condition, users associated with ALL methods are ignored when the Policy Condition is created.

Java Naming and Directory Interface (JNDI) Resources

A Java Naming and Directory Interface (JNDI) resource is a specific type of WebLogic resource that uses the industry-standard JNDI SPI to enable connectivity to heterogeneous enterprise naming and directory services.

A JNDI provides a common-denominator interface to many existing naming services, such as Lightweight Directory Access Protocol (LDAP) and Domain Name System (DNS). These naming services maintain a set of bindings, which relate names to objects and provide the ability to look up objects by name. JNDI allows the components in distributed applications to locate each other.

A JNDI is independent of any specific naming or directory service implementation. It supports the use of a number of methods for accessing various new and existing services. This support allows any service-provider implementation to be plugged into the JNDI framework using the standard service provider interface (SPI) conventions.

JNDI Operations

To secure access to the JNDI tree, create security policies and security roles for the entire JNDI tree, or for an individual branch of that tree. Regardless, you can protect all operations, or protect one of the following operations:

modify—Whenever an application modifies the JNDI tree in any way (that is, adding, removing, changing) the current user must have permission to make the modification. This includes the bind(), rebind(), createSubContext(), destroySubContext(), and unbind() methods.
lookup—Whenever an application looks up an object in the JNDI tree, the current user must have permission to perform the lookup. This includes the lookup() and lookupLink() methods.
list—Whenever an application lists the contents of a context in JNDI, the current user must have permission to perform the listing operation. This includes the list() and listBindings() methods.

Server Resources

A Server resource determines who can control the state of a WebLogic Server server instance.

When users start server instances by directly invoking the weblogic.Server class in a Java command, the policy on the Server resource is the only security check that occurs. All other tasks that change the state of a WebLogic Server instance require the use of the Administration Console, WebLogic Scripting Tool, Node Manager, or some other JMX client, and therefore require users to be authorized first by an additional security layer called the MBean security layer. See MBean Security Layer.

You can create security policies that apply to all WebLogic Server instances in a domain or to individual servers. If you define a policy for an individual server, you can protect all of its life cycle operations or define individual policies for each of the following operations:

boot—A user who tries to start a WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through a call to the java weblogic.Server command on the command line, by a configured start script (which in turn calls the java weblogic.Server command), or through the Node Manager capabilities that allow for remote start of WebLogic Server
shutdown—A user who tries to shut down a running WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through the WebLogic Server Administration Console or the WLST SHUTDOWN or FORCESHUTDOWN commands.
suspend—A user who tries to prohibit additional logins (logins other than for privileged administrative actions) to a running WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through the Administration Console.
resume—A user who tries to re-enable non-privileged logins to a running WebLogic Server instance, either an Administration Server or Managed Server, must have permission to do so. This action is typically initiated through the Administration Console.

All server resources inherit a default security policy that gives permission to the Admin and Operator global security roles.

Note: If you enable the domain-wide administration port, then only the Admin role (and not Operator) can control the state of a WebLogic Server server instance. See Configure the domain-wide administration port in Administration Console Online Help.

Caution: Do not remove roles from the default security policies. Eliminating some of the existing security roles might negatively affect 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). See Maintaining a Consistent Security Scheme.

Permissions for the weblogic.Server Command and the Node Manager

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.

Permissions for Using the weblogic.Server Command

The weblogic.Server command, which you can use to start both Administration and Managed Servers, 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 weblogic.Server Command-Line Reference in the WebLogic Server Command Reference.

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 configure 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 more information, see Using Node Manager to Control Servers in Managing Server Startup and Shutdown.

Shutting down a WebLogic Server instance 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 security layer). 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.

For more information about shutting down a WebLogic Server instance, see Starting and Stopping Servers: Quick Reference in Configuring and Managing WebLogic Server.

Web Application Resources

A Web application resource is a specific type of WebLogic resource accessed using the URL in a Web browser. To secure Web applications, you create security policies and security roles for a stand-alone Web application, the URL representing the Web Application in an EAR, or for individual components of a Web application. You can also secure specific HTTP methods for URL resources.

Because the J2EE platform standardizes Web application security in deployment descriptors, WebLogic Server integrates this standard mechanism with its Security Service to give you a choice of techniques for securing Web application resources. For more information, see Options for Securing Web Application and EJB Resources.

Web Service Resources

A Web Service resource is a specific type of WebLogic resource related to Web Services. To secure Web Services, you can create security policies and security roles for:

The entire Web Service
A subset of the operations of the Web Service
The stateless session EJB that implements the Web Service
A subset of the methods of the stateless session EJB

If your Web Service is implemented with a Java class, then the Web application WAR file contains the Java class files.

If the Web Service is implemented with a stateless session EJB, then the Enterprise Application EAR file contains the corresponding EJB JAR file.

Note: A Web Service can also be packaged as a stand-alone Web application WAR file if the Web Service is implemented with just a Java class. This type of packaging for a Web Service is uncommon; typically, Web Services are packaged as EAR files.

For more information, see Configuring Security in Programming Web Services for WebLogic Server.

Work Context Resources

Work Contexts enable J2EE developers to define properties as application context which implicitly flow across remote requests and allow downstream components to work in the context of the invoking client. Work Contexts allow developers to pass properties without including them in a remote call. A Work Context is propagated with each remote call, allowing the called component to add or modify properties defined in the Work Context. Similarly, the calling component can access the Work Context to obtain new or updated properties.

For more information, see Best Practices for Application Design in Programming WebLogic RMI.

You can use the Administration Console to specify a path for a Work Context resource and secure read, create, modify and/or delete actions.