Programming WebLogic Security

Using Java Security to Protect WebLogic Resources

This section discusses the following topics:

Using Java EE Security to Protect WebLogic Resources

WebLogic Server supports the use of Java EE security to protect URL (Web), Enterprise JavaBeans (EJBs), and Connector components. In addition, WebLogic Server extends the connector model of specifying additional security policies in the deployment descriptor to the URL and EJB components.

The connector specification provides for deployment descriptors to specify additional security policies using the <security-permission> tag (see Listing 8-1):

<security-permission>
<description> Optional explanation goes here </description>
<security-permission-spec>
<!—
A single grant statement following the syntax of http://java.sun.com/j2se/1.4.2/docs/guide/security/PolicyFiles.html#FileSyntax without the “codebase” and “signedBy” clauses goes here. For example:
-->
grant {
permission java.net.SocketPermission “*”, “resolve”;
};
</security-permission-spec>
</security-permission>

Besides support of the <security-permission> tag in the rar.xml file, WebLogic Server adds the <security-permission> tag to the weblogic.xml and weblogic-ejb-jar.xml files. This extends the connector model to the two other application types, Web applications and EJBs, provides a uniform interface to security policies across all component types, and anticipates future Java EE specification changes.

Using the Java Security Manager to Protect WebLogic Resources

The Java Security Manager can be used with WebLogic Server to provide additional protection for resources running in a Java Virtual Machine (JVM). Using a Java Security Manager is an optional security step. The following sections describe how to use the Java Security Manager with WebLogic Server:

For more information on Java Security Manager, see the Java Security Web page at http://java.sun.com/j2se/1.5.0/docs/guide/security/index.html.

Setting Up the Java Security Manager

When you run WebLogic Server under Java 2 (SDK 1.2 or later), WebLogic Server can use the Java Security Manager in Java 2, which prevents untrusted code from performing actions that are restricted by the Java security policy file.

The JVM has security mechanisms built into it that allow you to define restrictions to code through a Java security policy file. The Java Security Manager uses the Java security policy file to enforce a set of permissions granted to classes. The permissions allow specified classes running in that instance of the JVM to permit or not permit certain runtime operations. In many cases, where the threat model does not include malicious code being run in the JVM, the Java Security Manager is unnecessary. However, when untrusted third-parties use WebLogic Server and untrusted classes are being run, the Java Security Manager may be useful.

To use the Java Security Manager with WebLogic Server, specify the -Djava.security.policy and -Djava.security.manager arguments when starting WebLogic Server. The -Djava.security.policy argument specifies a filename (using a relative or fully-qualified pathname) that contains Java 2 security policies.

WebLogic Server provides a sample Java security policy file, which you can edit and use. The file is located at WL_HOME\server\lib\weblogic.policy.

For example, to successfully start WLS and deploy an application via the Administration Console, you might need to add permissions such as the following to weblogic.policy:

permission java.util.PropertyPermission '*', 'read'; 
permission java.lang.RuntimePermission '*'; 
permission java.io.FilePermission ' <<ALL FILES>>', 'read,write'; 
permission javax.management.MBeanPermission '*', '*';

If you enable the Java Security Manager but do not specify a security policy file, the Java Security Manager uses the default security policies defined in the java.policy file in the $JAVA_HOME\jre\lib\security directory.

Define security policies for the Java Security Manager in one of the following ways:

Modifying the weblogic.policy file for General Use

To use the Java Security Manager security policy file with your WebLogic Server deployment, you must specify the location of the weblogic.policy file to the Java Security Manager when you start WebLogic Server. To do this, you set the following arguments on the Java command line you use to start the server:

For example:

java...-Djava.security.manager \
   -Djava.security.policy==c:\weblogic\weblogic.policy

If you have extra directories in your CLASSPATH or if you are deploying applications in extra directories, add specific permissions for those directories to your weblogic.policy file.

Oracle recommends taking the following precautions when using the weblogic.policy file:

For more information about the Java Security Manager, see the Javadoc for the java.lang.SecurityManager class.

Setting Application-Type Security Policies

Set default security policies for Servlets, EJBs, and Java EE Connector Resource Adapters in the Java security policy file. The default security policies for Servlets, EJBs, and Resource Adapters are defined in the Java security policy file under the following codebases:

Setting Application-Specific Security Policies

Set security policies for a specific Servlet, EJB, or Resource Adapter by adding security policies to their deployment descriptors. Deployment descriptors are defined in the following files:

Listing 8-2 shows the syntax for adding a security policy to a deployment descriptor:

<security-permission>
 <description>
  Allow getting the J2EEJ2SETest4 property
 </description>
 <security-permission-spec>
  grant {
    permission java.util.PropertyPermission "welcome.J2EEJ2SETest4","read";
  };
 </security-permission-spec>
</security-permission>

Using the Java Authorization Contract for Containers

The Java Authorization Contract for Containers (JACC) is part of Java EE. JACC extends the Java 2 permission-based security model to EJBs and Servlets. JACC is defined by JSR-115.

JACC provides an alternate authorization mechanism for the EJB and Servlet containers in a WebLogic Server domain. As shown in Table 8-1, when JACC is configured, the WebLogic Security framework access decisions, adjudication, and role mapping functions are not used for EJB and Servlet authorization decisions.

WebLogic Server implements a JACC provider which, although fully compliant with JSR-115, is not as optimized as the WebLogic Authorization provider. The Java JACC classes are used for rendering access decisions. Because JSR-115 does not define how to address role mapping, WebLogic JACC classes are used for role-to-principal mapping. See http://java.sun.com/j2ee/javaacc for information on developing a JACC provider.

This section discusses the following topics:

Table 8-1 shows which providers are used for role mapping when JACC is enabled.

Comparing the WebLogic JACC Provider with the WebLogic Authentication Provider

The WebLogic JACC provider fully complies with JSR-115; however, it does not support dynamic role mapping, nor does it address authorization decisions for resources other than EJBs and Servlets. For better performance, and for more flexibility regarding security features, Oracle recommends using SSPI-based providers.

Table 8-2 compares the features provided by the WebLogic JACC provider with those of the WebLogic Authorization provider.

Enabling the WebLogic JACC Provider

To enable the WebLogic JACC Provider from the command line, you must specify the following system property/value pairs:

For example, assuming a properly configured weblogic.policy file, the following command line will enable the WebLogic JACC provider:

# ./startWebLogic.sh -Djava.security.manager\
-Djava.security.policy==<pathname>/weblogic.policy \
-Djavax.security.jacc.policy.provider=\
weblogic.security.jacc.simpleprovider.SimpleJACCPolicy \
-Djavax.security.jacc.PolicyConfigurationFactory.provider=\
weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl \
-Dweblogic.security.jacc.RoleMapperFactory.provider=\
weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl