Securing WebLogic Resources
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
![]() |
The following sections describe the types of resources that you can secure using the WebLogic Server Administration Console:
A WebLogic resource represents any software component, such as a server, a service, an application, or an application artifact. In the context of this document, a WebLogic resource is any type of resource that can be secured using security roles and policies. WebLogic resources are hierarchical. The level at which you define security roles and security policies is up to you. For example, you can define security roles and security policies for an entire enterprise application (EAR), an Enterprise JavaBean (EJB) JAR containing multiple EJBs, a particular EJB within that JAR, or a single method within that EJB.
An Administrative resource is a type of WebLogic resource that allows users to perform administrative tasks. Examples of Administrative resources include the WebLogic Server Administration Console, the WebLogic Scripting Tool (WLST), and MBean APIs.
Administrative resources are similar to Server resources in that both are controlled by a layered security scheme that combines security policies and MBean protections. See Layered Security Scheme for Server Resources
When you secure Administrative resources, you can choose to protect all or any one of the operation categories defined in the WebLogic server's realm AdminResource
object. These are described in Table 3-1.
Allows user to access |
||
Allows user access to configuration operations Note: BEA recommends that you not add groups for this category but rather add users to the default groups. Adding groups might interfere with the Layered security scheme. See Layered Security Scheme for Server Resources. |
||
Allows user access to file upload operations on specified resources in the AdminResource object. |
||
Allows users to access these methods in the AdminResource object: |
||
Allows user access to view log operations on specified resources in the AdminResource object. |
||
Allows user access to the |
For more information, see Default Groups and Default Global Roles.
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.
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.
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.
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 EJB and Web Application 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.
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 are an Oracle user, 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.
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.
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:
To secure a resource for send
, receive
, and browse
methods on a destination:
Note: You may need to update the Providers and Policy Conditions on this page. See "Security Policies in Securing WebLogic Resources.
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.
To individually secure a resource for send
, receive
, or browse
for a destination:
Note: You may need to update the Providers and Policy Conditions on this page. See "Security Policies in Securing WebLogic Resources.
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.
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.
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.
A Server resource is a specific type of WebLogic resource that is used to control the state of a WebLogic Server server instance. To secure Server resources, you create security policies and security roles for all WebLogic Server instances as a group, or individual servers.
Before securing WebLogic servers you need to understand the layered security scheme. See Layered Security Scheme for Server Resources.
When you are ready to secure a particular server, you can protect all operations on the server, or protect any 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 Servershutdown
—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. The WebLogic scheme for securing server resources consists of two parts (or layers): security policies and MBean protections.
Like other types of WebLogic resources, access to Server resources is controlled with security policies created in the WebLogic Server Administration Console.
All server resources inherit a default security policy that is based on the Admin
and Operator
default global security roles. As described in Default Global Roles, the Admin
and Operator
global roles are granted specific privileges required for administrators to interact with administrative interfaces such as the Administration Console or the WLST utility. These default global roles are based on the default groups (described in Default Groups). Therefore, administrators who need access to Server resources must be members of either the Administrators
or Operators
default groups.
Notes: 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.
If you enable the Domain-Wide Administration port, then only members of the Administrators
(and not Operators
) can access the securable server operations. see Server Operations and Configure the domain-wide administration port in Administration Console Online Help.
Caution: Do not modify the default security policies for Server resources to make them more restrictive. 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).
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 Default 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 unconfigurable protection supplied by the WebLogic Security Service. Therefore, although you can create your own global roles for securing Server resources, only users granted one of the default global roles can view or change the configuration of a server.
When a user tries to interact with a Server resource, the WebLogic Security Service:
Therefore, a user must satisfy both of these security schemes for the request to be successful. Figure 3-1 shows 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.
The WebLogic Server 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. Be certain 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 (which is not one of the default policies for the server resource) but fail to add 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 not currently configurable.
To keep MBean protections synchronized with security policies, consider taking the following actions when you create or modify a security policy:
Admin
global role access to a Server resource.Operator
global role. 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.
Deployer
global role.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 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.
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 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.
For more information about shutting down a WebLogic Server instance, see Starting and Stopping Servers: Quick Reference in Configuring and Managing WebLogic Server.
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 EJB and Web Application 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:
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 Contexts allow 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.
The way you access resources in the Administration console depends on how it is deployed. In addition, you can access security roles and policies for resources using the Domain Structure in the Administration console or, for central management you can use the Roles and Policies tables. For more information, see Create scoped security roles and Create security policies in Administration Console Online Help.
![]() ![]() |
![]() |
![]() |