WebLogic Resources

A WebLogic resource is a structured object used to represent an underlying WebLogic Server entity, which can be protected from unauthorized access using security roles and security policies.

WebLogic resources are hierarchical. Therefore, the level at which you define these security roles and security policies is up to you. For example, you can define security roles and security policies on an entire enterprise application (EAR), an Enterprise JavaBean (EJB) JAR containing multiple EJBs, a particular Enterprise JavaBean (EJB) within that JAR, or a single method within that EJB.

 

 

Types of WebLogic Resources

WebLogic Server defines the resources shown in Table  2-1.

Table 2-1 WebLogic Resources
Type Description
Administrative resources Resources that allow users to perform administrative tasks. This type of WebLogic resource includes the WebLogic Server console, the weblogic.Admin tool, and MBean APIs.
Application resources Resources that represent enterprise applications, packaged as EAR (Enterprise Application aRchive) files. One uses this type of WebLogic resource when you want to protect all EJBs (Enterprise JavaBeans) within an entire application.
COM resources
(Component Object Model) 		Resources that are designed as program component objects according to Microsoft's framework. This type of WebLogic resource includes COM components accessed through BEA's bi-directional COM-Java (jCOM) bridging tool.
EIS resources
(Enterprise Information System) 		Resources that are designed as connectors, which allow for the integration of Java applications with existing enterprise information systems. These connectors are also known as resource adapters.
EJB resources
(Enterprise JavaBean) 		Resources that are related to EJBs. One uses this type of WebLogic resource when you want to protect EJB JARs, individual EJBs within an EJB JAR, or individual methods on an EJB.
JDBC resources
(Java DataBase Connectivity) 		Resources that are related to JDBC. This type of WebLogic resource includes groups of connection pools, individual connection pools, and multipools.
JNDI resources
(Java Naming and Directory Interface) 		Resources that use the industry-standard JNDI API to enable connectivity to heterogeneous enterprise naming and directory services.
JMS resources
(Java Messaging Service) 		Resources that are related to JMS.
Server resources Resources that are related to WebLogic Server instances, or servers. This type of WebLogic resource includes operations that start, shut down, lock, or unlock servers.
URL resources (previously Web resources, deprecated) Resources that are related to Webapps. This type of WebLogic resource can be a WAR (webapp aRchive) file or individual components of a Webapp (such as servlets and JSPs ).
Web Services resources Resources that are related to services, which can be shared by and used as components of distributed, Web-based applications. This type of WebLogic resource can be an entire Web service or individual components of a Web Service (such as a stateless session EJB, particular methods on that EJB, the Webapp that contains the web-services.xml file, and so on).


 

 

Techniques for Securing URL (Web) and EJB Resources

You can secure most types of WebLogic resources (described in Types of WebLogic Resources ) using the WebLogic Server console. However, because the Java 2 Enterprise Edition (J2EE) platform standardizes URL (Web) and Enterprise JavaBean (EJB) security in deployment descriptors, WebLogic Server integrates this standard mechanism with its Security Service to give you a choice of two techniques.

The technique you choose will affect the procedure you will follow to secure your URL and EJB resources. The following sections describe the different techniques in more detail:

 

 

Using the WebLogic Server console

The first technique for securing your URL (Web) and Enterprise JavaBean (EJB) resources is to use the WebLogic Server console. The primary benefit of this technique is unified security management. Instead of requiring developers to modify multiple deployment descriptors when organizational security requirements change, administrators can modify all security configurations from a centralized, graphical user interface. Users, groups, security roles, and security policies can all be defined using the console. As a result, the process of making changes based on updated security requirements becomes more efficient.

With the exception of Web Services resources, you can secure all types of WebLogic resources (described in Types of WebLogic Resources ) using this technique. Therefore, the instructions for securing WebLogic resources contained within this document are written specifically for users of the console.

 

 

Using Deployment Descriptors

The second technique for securing your URL (Web) and Enterprise JavaBean (EJB) resources is to use the Java 2 Enterprise Edition (J2EE) and WebLogic deployment descriptors. The primary benefit of this technique is that it is a widely-known, standard technique for adding declarative security to URLs and EJBs. It may also be the technique with which most organizations are familiar. This technique implies that users and groups may be defined in the WebLogic Server console, but that security roles and security policies may be specified in the web.xml, weblogic.xml, ejb-jar.xml, and weblogic-ejb-jar.xml deployment descriptors.

Note: In WebLogic Server 7.0 SP02, a special tag called <externally-defined> was introduced. This tag allows you to specify on a role-by-role basis whether a role mapping is defined in the deployment descriptors or in the console. This tag replaces the <global-role> tag, which has been deprecated.

You can secure only URL and EJB resources using this technique. The instructions for using deployment descriptors are available in the Adding Declarative Security to webapps and Adding Declarative Security to EJBs sections of Programming WebLogic Security, respectively.

 

 

Combining the Two Techniques

Some organizations currently using deployment descriptors to secure their URL (Web) and Enterprise JavaBean (EJB) resources may want to take advantage of the unified security management capabilities that the WebLogic Server console provides. In a situation like this, the console can be instructed to copy security configurations from existing deployment descriptors upon the initial deployment of a URL or EJB resource. Once these security configurations are copied, the console can be used for subsequent updates. It is also possible to use this combined technique to reinitialize security configurations for URL and EJB resources to the state specified in the deployment descriptors.

Warning: When using the combined technique, it is possible to override security configurations for URL and EJB resources. Therefore, administrators using the combined technique need to take extra care to ensure that the appropriate security configuration is in place for their URLs and EJBs. Read Prerequisites for Securing URL (Web) and EJB Resources for important information.

 

 

Prerequisites for Securing URL (Web) and EJB Resources

Whether using the WebLogic Server console or deployment descriptors to secure your URL (Web) and Enterprise JavaBean (EJB) resources, there are two important settings in WebLogic Server that you need to understand. Failure to understand these settings could result in incorrect or lost security configurations.

Before continuing, read the following sections:

 

 

Understanding How to Check Security Roles and Security Policies

To give you control over performance, the WebLogic Server console requires you to specify how the WebLogic Security Service should perform security checks. You specify this preference using the Check Roles and Policies setting, the first of the two drop-down menus highlighted in Figure  2-1. Figure 2-1 console : Security > Realms > myRealm > General


When the value of the Check Roles and Policies setting is: webapps and EJBs Protected in DD, the WebLogic Security Service only performs security checks on URL and EJB resources that have security specified in their associated deployment descriptors (DDs). This is the default Check Roles and Policies setting.

When the value of the Check Roles and Policies setting is: All webapps and EJBs, the WebLogic Security Service performs security checks on all URL (Web) and EJB resources, regardless of whether there are any security settings in the deployment descriptors (DDs) for these WebLogic resources. If you change the value of the Check Roles and Policies drop-down menu to All webapps and EJBs, you also need to specify what the WebLogic Security Service should do when the URL or EJB resource is redeployed.

Note: The Check Roles and Policies setting only has an effect on the WebLogic Server instances (servers) in which it is set. Therefore, you should ensure that the Check Roles and Policies setting is set the same way for both your Administration and Managed Servers.

 

 

Understanding What to Do on Future Redeploys of the WebLogic Resource

If you decide that the WebLogic Security Service should perform security checks on All Webapps and EJBs in the Check Roles and Policies drop-down menu, you also need to tell WebLogic Server which technique you want to use to secure these URL (Web) and EJB resources. You specify this preference using the Future Redeploys setting, the second of the two drop-down menus highlighted in Figure  2-1.

You should set the value of the Future Redeploys drop-down menu as follows:

Warning: Switching the value of the Future Redeploys setting is risky and can lead to incorrect or lost security configurations. If you need to switch between these settings (specifically for the situations described in Combining the Two Techniques ), you can carefully follow the instructions in Using the Combined Technique to Secure Your URL (Web) and Enterprise JavaBean (EJB) Resources.

 

 

How to Change the Check Roles and Policies and Future Redeploys Settings

To change the values of the Check Roles and Policies and Future Redeploys settings, follow these steps:

  1. Using the navigation tree at the left side of the WebLogic Server console, click Security - > Realms.
  2. Click the name of a security realm for which you are setting this option (for example, myrealm).
  3. On the General tab, change the value of the Check Roles and Policies drop-down menu.
  4. If you changed the value of the Check Roles and Policies drop-down menu to All webapps and EJBs, change the value of the Future Redeploys drop-down menu.
  5. Click the Apply button to save your changes.
  6. If you changed the value of the Check Roles and Policies drop-down menu, restart the server.

 

 

Understanding How These Settings Interact

Table  2-2 shows how to achieve the behavior you want from the WebLogic Security Service using different combinations of the Check Roles and Policies and Future Redeploys settings.

Note: The WebLogic Server default for these settings is shown in the last row.

Table 2-2 How These Settings Interact
If you want to... Then set Check Roles and Policies to... and set Future Redeploys to...
Perform security checks on all URL (Web) and EJB resources, and set security for URL and EJB resources using the console only All webapps and EJBs Ignore Roles and Policies from DD
Perform security checks on all URL (Web) and EJB resources and copy security for URL and EJB resources from the deployment descriptors into the configured Authorization and Role Mapping providers' databases each time you deploy the resource. Then, make changes using the console, or by modifying the deployment descriptor and redeploying the Webapp or EJB JAR All webapps and EJBs Initialize Roles and Policies from DD
Only perform security checks on URIs and EJB methods that are specified in the deployment descriptors and set security for URL (Web) and EJB resources in the deployment descriptors webapps and EJBs Protected in DD --