Resource Types You Can Secure with Policies

Administrative Resources

Policies for administrative resources are different from the policies defined for regular users. Administrative resources have special privileges such as uploading files during deployment, viewing the domain and server logs, and unlocking users, and so on.

Policies for administrative resources determine who can complete such tasks as uploading files (used during deployment), viewing the domain and server logs, and unlocking users who have been locked out of their accounts.

For the most security-sensitive of these tasks, users must first be authorized by additional policies on a JMX resource (see Figure 3-1). For information about JMX resources and how to design roles and policies for activities that are protected by multiple resources, see JMX Resources.

Figure 3-1 Some Policies Overlap

Description of "Figure 3-1 Some Policies Overlap"

Table 3-1 describes the administrative activities that administrative resources protect and which of these activities are also protected by additional JMX resources. For activities that are protected by multiple resources, the default policy in the JMX resource duplicates the protections in the Administrative resource.

Table 3-1 Activities And Default Policies For Administrative Resources

Administrative Activities	Default Policy Allows These Roles	Also Protected By a JMX Resource?
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. Oracle recommends that you do not modify the default policies for any of its methods. They are listed here only for completeness.	`Admin`, `Operator`	No
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 Java API Reference for Oracle WebLogic Server.	`Admin`	No
View domain and server logs through the WebLogic Server Administration Console.	`Admin`, `Deployer`, `Operator`, `Monitor`	Yes
Unlock users who have been locked out of their accounts.	`Admin`	Yes

Application Resources

An application resource is an enterprise application, Web application, or other Java EE module that you deploy as a stand-alone application (for example, you can deploy Web Services and JDBC modules as stand-alone applications). You secure an application resource when you want to protect all resources that constitute the application. For example, securing an enterprise application protects access to all WebLogic resources within that application (see Figure 3-2).

Figure 3-2 Application Resource Protects All Resources

Description of "Figure 3-2 Application Resource Protects All Resources"

See Protecting a Hierarchy of Resources.

COM Resources

A COM resource represents a package that contains one or more jCOM classes. jCOM is a software bridge that allows bidirectional access between Java/Java EE 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 policy on a COM resource protects access to all jCOM objects in a package.

For related information, see Configuring Access Control in Developing JCOM Applications for Oracle WebLogic Server.

EJB Resources

An EJB (Enterprise JavaBean) resource is an EJB deployment module (JAR), individual EJB, or individual method in an EJB. EJB resources exist within a hierarchy of resources, and at the top of the hierarchy is an application resource. See Protecting a Hierarchy of Resources.

Because the Java EE 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. See Options for Securing Web Application and EJB Resources.

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. Oracle supports resource adapters developed by EIS vendors and third-party application developers. Resource adapters can be deployed in any application server supporting the applicable Java EE 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. These resources exist within a hierarchy of resources, and at the top of the hierarchy is an application resource. See Protecting a Hierarchy of Resources.

For related information, see Security in Developing Resource Adapters for Oracle WebLogic Server.

Java DataBase Connectivity (JDBC) Resources

A Java DataBase Connectivity (JDBC) resource is a JDBC system resource, JDBC module that is part of an application, JDBC data source, or a specific method within a data source. If you deploy a JDBC module as a stand-alone application, the application is represented by an application resource (see Application Resources).

JDBC resources exist within a hierarchy of resources, and at the top of the hierarchy is an application resource. See Protecting a Hierarchy of Resources.

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, start, 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 specific security policy controls access.

Table 3-2 lists the JDBC administrator methods and the roles that the default policy allows for each operation.

Table 3-2 Default Policies for JDBC Resources

JDBC Administrator Methods	Default Policy Allows These Roles
`admin`	`Admin`, `Deployer`
`reset`	`Admin`, `Deployer`
`reserve`	`Everyone`
`shrink`	`Admin`, `Deployer`

Java Messaging Service (JMS) Resources

A Java Messaging Service (JMS) resource is a JMS system module, a JMS module that is part of an application (deprecated), a specific WebLogic JMS destination or destination template defined within a module, or a specific operation within a WebLogic JMS destination. You can create security policies and roles for WebLogic JMS destinations (JMS queues and JMS topics) as a group by securing the JMS module where they are defined, or for specific WebLogic JMS destinations (JMS queues or JMS topics) defined within a JMS module. The WebLogic destinations defined in a JMS module run on WebLogic JMS Servers.

These resources exist within a hierarchy of resources, and at the top of the hierarchy is an application resource. See Protecting a Hierarchy of Resources.

JMS Operations

When you secure a specific 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.

Java Naming and Directory Interface (JNDI) Resources

A Java Naming and Directory Interface (JNDI) resource is a node in a server's JNDI tree. A policy on a JNDI resource determines who can access WebLogic Server entities and actions through JNDI. You can create a policy on the root node of the JNDI tree or on individual nodes.

If your domain is configured to run in secured production mode, then the authorization policies for JNDI and MBean access are more restrictive to enforce a highly secure environment for your production domain. In this mode, remote anonymous JNDI access is not allowed for modify and list operations. This is enforced by the RemoteAnonymousJNDIEnabled attribute in the SecurityConfigurationMBean. This attribute disables anonymous JNDI access and the default value, in secured production mode, is true. See SecurityConfigurationMBean in MBean Reference for Oracle WebLogic Server for more information about this MBean attribute. When in secured production mode, only the standard roles (Admin, Deployer, Operator, and Monitor) can look up MBeans using the JNDI lookup methods.

JNDI Operations

For each JNDI node, you can create a policy for all operations or for 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.

If your domain is configured to run in secured production mode, then only the standard roles (Admin, Deployer, Operator, and Monitor) can look up MBeans using the JNDI lookup methods. For more information about secured production mode, see Install WebLogic Server in a Secure Manner in Securing a Production Environment for Oracle WebLogic Server.
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.

JMX Resources

A JMX resource is an MBean attribute or MBean operation. A policy on a JMX resource controls who can read or write MBean attributes or invoke operations.

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

Oracle provides a default set of JMX resources to protect WebLogic Server MBeans. See Default Security Policies for MBeans in the MBean Reference for Oracle WebLogic Server. For MBean attributes and operations that represent particularly sensitive data or actions, WebLogic Server uses additional types of resources to secure access. For example, the ServerLifeCycleRuntimeMBean's shutdown() operation is protected by a JMX resource and a Server resource.

If your domain is configured to run in secured production mode, then more restrictive policies are enabled by default for JMX authorization. If you enable restrictive JMX policies, then the default policies allow MBean access only to the standard WebLogic Server roles (Admin, Deployer, Operator, or Monitor). You can enable or disable restrictive JMX policies as follows:

Use the WebLogic Server Administration Console. In the left pane under Domain Structure, select the domain name, and select Security > General under settings for your domain. Expand the Advanced node and scroll down to Secure Mode Settings. Under Secure Mode Settings, select the Restrictive JMX Policies check box. See Secure your production domain in Oracle WebLogic Server Administration Console Online Help for information about enabling secured production mode for your domain.

When a JMX client attempts to invoke an operation or change an attribute that is secured by a JMX resource and some other resource type, the client must satisfy the policies defined in both resources (see Figure 3-3).

Figure 3-3 MBean Server Checks with Both Resources

Description of "Figure 3-3 MBean Server Checks with Both Resources"

Maintaining a Consistent Security Scheme

The default configuration of groups, global roles, and security policies on all resources that are used to protect an entity or action 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 JMX resource and other resource type. When you create or modify a security policy, consider taking the following action:

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.

Server Resources

Policies for a server resource determine 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 WebLogic Server Administration Console, WebLogic Scripting Tool, Node Manager, or some other JMX client, and therefore require users to be authorized first by an additional JMX resource. See JMX Resources.

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 WebLogic Server 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 WebLogic Server 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 Oracle WebLogic Server Administration Console Online Help.

Note:

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.

See weblogic.Server Command-Line Reference in the Command Reference for Oracle WebLogic Server.

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.

See Node Manager Overview in Administering Node Manager for Oracle WebLogic Server.

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.

See Starting and Stopping Servers: Quick Reference in Administering Server Startup and Shutdown for Oracle WebLogic Server.

URL Resources

A URL resource is a specific URL or URL pattern in a Web application. You can create a policy for a URL resource that protects all HTTP methods for a specified URL or URL pattern, or that protects only specific HTTP methods. These resources exist within a hierarchy of resources, and at the top of the hierarchy is an application resource. See Protecting a Hierarchy of Resources.

Because the Java EE 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. See Options for Securing Web Application and EJB Resources.

Web Service Resources

A Web Service resource is a Web Service module (WAR or JAR) or an operation within a Web Service module. Web Services are protected by the following hierarchy of resources:

The application resource for the parent application.
The Web Service resource for the Web Service module (WAR or JAR).
Individual Web Service resources for each Web Service operation.

If you implement the Web Service with standard Java objects, any of the above resources protect the Java objects.

If you implement the Web Service with an EJB any of the above or any of the following resources protect the EJB implementation:
- The EJB resource for the EJB.
- Individual EJB resources for each EJB method.

If you use an EJB to implement your Web Service, Oracle recommends that you create a policy at the application level. Policies on the Web Service module and individual Web Service operations apply only to Web Service clients. EJB clients can use RMI or JNDI to bypass the Web Service module and directly invoke EJB operations (see Figure 3-4).

Figure 3-4 Hierarchy of Resources for Web Service with EJB Implementation

Description of "Figure 3-4 Hierarchy of Resources for Web Service with EJB Implementation"

For information on using Java annotations to secure Web Services, see Configuring Message-Level Security in Securing WebLogic Web Services for Oracle WebLogic Server.

Work Context Resources

Work Contexts enable Java EE developers to define and pass properties without including them in a remote call. A Work Context resource represents the operations that create, delete, read, or modify a property. You can use one Work Context resource for all operations of a given property, or you can create individual resources for each operation.

See Best Practices for Application Design in Developing RMI Applications for Oracle WebLogic Server.

Coherence Resources

Coherence resources provide distributed, in-memory caching and data grid processing for applications. Roles and policies can be applied to two types of Coherence resources:

Caches – A cluster contains any number of caches that are shared by all cluster members. The caches are used by applications to store and retrieve data.
Services – A cluster contains any number of services that are shared by all cluster members. The services include connectivity services, cache services, and processing services. Each cluster member can provide and consume such services.

The default authorization policy allows everybody access to all Coherence resources. To define policies and roles on caches and services, the names of the caches and services must be known. In some cases, the cache configuration file in a Coherence Grid ARchive (GAR) module can be inspected to discover cache and service names. However, there are some configurations that allow applications to use different names to refer to the same cache. Always consult an application's developers or architects to be certain of the cache and service names used by an application.