Skip navigation.

Securing WebLogic Resources

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Types of WebLogic Resources

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

 


Overview of WebLogic Resource Types

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.

 


Administrative Resources

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

Administrative Operations

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.

Table 3-1 Categories And Default Groups For Administrative Resources

Administrative Category

Accessible Operations

Default Group Access

UserLockout

Allows user to access unlockuser to unlock users who have been locked out of their accounts.

Administrators

Configuration

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.

Administrators, Deployers, Operators Monitors

FileUpload

Allows user access to file upload operations on specified resources in the AdminResource object.


Administrators, Deployers

FileDownload

Allows users to access these methods in the AdminResource object:

  • 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

Administrators, Operators

ViewLog

Allows user access to view log operations on specified resources in the AdminResource object.

Administrators, Deployers, Operators Monitors

Identity Assertion

Allows user access to the assertIdentity action in the AdminResource object.

Administrators

For more information, see Default Groups and Default Global Roles.

 


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 EJB and Web Application 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:

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.

 


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:

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:

  1. On the Security > Policies tab, select ALL from the Methods drop-down box.
  2. Note: You may need to update the Providers and Policy Conditions on this page. See "Security Policies in Securing WebLogic Resources.

  3. 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:

  1. On the Security > Policies tab, select send, receive, or browse from the Methods drop-down box.
  2. Note: You may need to update the Providers and Policy Conditions on this page. See "Security Policies in Securing WebLogic Resources.

  3. 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:

 


Server Resources

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.

Server Operations

When you are ready to secure a particular server, you can protect all operations on the server, or protect any of the following operations:

Layered Security Scheme for Server Resources

The WebLogic scheme for securing server resources consists of two parts (or layers): security policies and MBean protections.

Default Security Policies for Server Resources

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

MBean Protections

Each type of WebLogic resource (including a Server resource) exposes a set of its operations through its own implementation of the weblogic.security.spi.Resource interface (the weblogic.security.service.ServerResource class for Server resources). Therefore, the ServerResource class is the entity that is actually secured by the security policy described in 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.

How the WebLogic Security Service Enforces Layered Protections

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

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.

Maintaining a Consistent Security Scheme

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:

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.

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

 


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 EJB and Web Application 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:

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

 


Accessing Resources Using the Administration Console

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.

 

Skip navigation bar  Back to Top Previous Next