7 Using Java Security Features to Protect WebLogic Resources

To protect WebLogic resources, Oracle WebLogic Server supports the use of Java security artifacts, such as Jakarta security, Java Security Manager, and Jakarta Authorization.

Using Jakarta Security to Protect WebLogic Resources

You can use Jakarta Security to protect URL (Web), EJBs, and Connector components. Additionally, 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 Example 7-1):

Example 7-1 Security-Permission Tag Sample

<security-permission>
<description> Optional explanation goes here </description>
<security-permission-spec>
<!--
A single grant statement following the syntax of http://xmlns.jcp.org/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 Jakarta EE specification changes.

Note:

Jakarta EE has requirements for Java security default permissions for different application types (see the Jakarta EE specification) as does the Jakarta Connector Architecture specification.

Using the Java Security Manager to Protect WebLogic Resources

You can set up the Java Security Manager to be used with WebLogic Server to provide additional protection for resources running in a Java Virtual Machine (JVM). You can also use Printing Security Manager which is an enhancement to the Java Security Manager.

Note:

The Java Security Manager was deprecated in JDK 17 and will be removed in a future release. WebLogic Server will display warnings if you start a server with the Java Security Manager enabled.

WebLogic Server will no longer support the Java Security Manager after it is removed from the JDK.

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://docs.oracle.com/javase/8/docs/technotes/guides/security/index.html.

Setting Up the Java Security Manager

When you run WebLogic Server, WebLogic Server can use the Java Security Manager, 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 security policies. If you're using Java Security Manager with WebLogic Server, then you must also specify the -Dweblogic.Name argument when starting WebLogic Server from the command line using the java weblogic.Server command. For example: 

java -Dweblogic.Name=server-name 
      -Djava.security.manager
      -Djava.security.policy[=]=filename
      weblogic.Server

WebLogic Server provides a sample Java security policy file located at WL_HOME\server\lib\weblogic.policy. Do not edit this file because it may be overwritten by Patch Set Updates (PSU). Instead, use it as a model to create your own security policy file. Consider concatenating the sample weblogic.policy file with your custom security policy file to automatically obtain any updates delivered in the PSU.

Note:

This sample policy file is not complete and is not sufficient to start WebLogic Server without modifications. When you create your own custom policy file, make sure that you add various permissions based on your configuration in order for WebLogic Server and all applications to work properly.

Pay particular attention if you apply patches. If you apply patches that include code with system privileges, you may need to make associated changes to any custom Java policy file you are using.

For example, to successfully start WebLogic Server and deploy an application using WebLogic Remote Console, you might need to add permissions such as the following to your custom policy file: 

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 your Custom 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 a custom policy file to the Java Security Manager when you start WebLogic Server. To do this, set the following arguments on the Java command line you use to start the server:

  • java.security.manager tells the JVM to use a Java security policy file.

  • java.security.policy tells the JVM the location of the Java security policy file to use. The argument is the fully qualified name of the Java security policy, which in this case, might be example.policy.

For example:

java...-Djava.security.manager \
   -Djava.security.policy==C:\weblogic\example.policy

Note:

Be sure to use == instead of = when specifying the java.security.policy argument so that only the example.policy file is used by the Java Security Manager. The == causes the example.policy file to override any default security policy. A single equal sign (=) appends the example.policy file to an existing security 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 example.policy file.

Oracle recommends taking the following precautions when using a policy file:

  • Do not make your changes to the WL_HOME\server\lib\weblogic.policy file directly as subsequent Patch Set Updates (PSUs) will overwrite your changes. Instead, create a custom policy file based off of WL_HOME\server\lib\weblogic.policy and apply your changes to the custom policy file. Consider configuring your custom policy file to automatically pull in the contents of WL_HOME\server\lib\weblogic.policy so you can get any changes from the PSU automatically.

  • Make a backup copy of your custom policy file and put the backup copy in a secure location.

  • Set the permissions on the custom policy file via the operating system such that the administrator of the WebLogic Server deployment has write and read privileges and no other users have access to the file.

    Note:

    The Java Security Manager is partially disabled during the booting of Administration and Managed Servers. During the boot sequence, the current Java Security Manager is disabled and replaced with a variation of the Java Security Manager that has the checkRead() method disabled. While disabling this method greatly improves the performance of the boot sequence, it also minimally diminishes security. The startup classes for WebLogic Server are run with this partially disabled Java Security Manager and therefore the classes need to be carefully scrutinized for security considerations involving the reading of files.

For more information about the Java Security Manager, see the Javadoc for the java.lang.SecurityManager class, available at http://docs.oracle.com/javase/8/docs/api/java/lang/SecurityManager.html.

Setting Application-Type Security Policies

Set default security policies for servlets, EJBs, and Jakarta Connector Architecture 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:

  • Servlets—"file:/weblogic/application/defaults/Web"

  • EJBs—"file:/weblogic/application/defaults/EJB"

  • Resource adapters—"file:/weblogic/application/defaults/Connector"

    Note:

    These security policies apply to all servlets, EJBs, and resource adapters deployed in the particular instance of WebLogic Server.

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:

  • Servlets—weblogic.xml

  • EJBs—weblogic-ejb-jar.xml

  • Resource adapters—rar.xml

    Note:

    The security policies for resource adapters follow the Jakarta EE standard while the security policies for servlets and EJBs follow the WebLogic Server extension to the Jakarta EE standard.

Example 7-2 shows the syntax for adding a security policy to a deployment descriptor:

Note:

The <security-permission-spec> tag cannot currently be added to a weblogic-application.xml file, you are limited to using this tag within a weblogic-ejb-jar.xml, rar.xml, or weblogic.xml file. Also, variables are not supported in the <security-permission-spec> attribute.

Example 7-2 Security Policy Syntax

<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 Printing Security Manager

Printing Security Manager is an enhancement to the Java Security Manager. You can use Printing Security Manager to identify all of the required permissions for any Java application running under Java Security Manager. Unlike The Java Security Manager, which identifies needed permissions one at a time, the Printing Security Manager identifies all of the needed permissions without intervention.

For more information on Java Security Manager, see the Java Security Web page at http://docs.oracle.com/javase/8/docs/technotes/guides/security/overview/jsoverview.html.

Note:

Do not use Printing Security Manager in production environments. It is intended solely for development to identify missing permissions.

It does not prevent untrusted code operations.

Printing Security Manager Startup Arguments

To use the Java Security Manager with WebLogic Server, you specify two arguments when starting WebLogic Server:

  • -Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

    The -Djava.security.manager argument tells WebLogic Server which Java Security Manager to start, in this case the Printing Security Manager.

  • -Djava.security.policy

    The -Djava.security.policy argument specifies a file name (using a relative or fully-qualified path name) that contains Java security policies. WebLogic Server provides a sample Java security policy file located at WL_HOME\server\lib\weblogic.policy. Do not use this file directly because it may be overwritten by Patch Set Updates (PSU). Instead, use it as a model to create your own security policy file. Consider concatenating the sample weblogic.policy file with your custom security policy file to automatically obtain any updates delivered in the PSU.

    By default, the startWebLogic script already includes the -Djava.security.policy property, which is set to WL_HOME/server/lib/weblogic.policy. Update the -Djava.security.policy to specify the file location of your custom policy file.

Note:

The sample policy file at WL_HOME\server\lib\weblogic.policy is not complete and is not sufficient to start WebLogic Server without first being modified. When you create your own custom policy file, make sure that you add various permissions based on your configuration in order for WebLogic Server and all applications to work properly.

See the following sections:

Starting WebLogic Server With Printing Security Manager

To start WebLogic Server with the Printing Security Manager from a UNIX shell, pass the following argument to the startWebLogic.sh script in DOMAIN_HOME. This example uses the default weblogic.policy Java policy file from startWeblogic.sh. 

startWeblogic.sh
-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

For a Windows system without a UNIX shell, first set the startup options in JAVA_OPTIONS, and then use the startWebLogic.cmd script in DOMAIN_HOME to start WebLogic Server. This example uses the default weblogic.policy Java policy file from startWeblogic.cmd. 

$ set JAVA_OPTIONS=-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager

$ DOMAIN_HOME\startWeblogic.cmd
Writing Output Files

Printing Security Manager generates output that lists which code source needs which permissions. It also generates a policy grant that you can copy and paste into the policy file.

By default, output is to System.out. You can configure output files via two arguments:

  • -Doracle.weblogic.security.manager.printing.file=psm_perms.txt

  • -Doracle.weblogic.security.manager.printing.generated.grants.file=psm_grants.txt

The value of the first system argument is a file to which Printing Security Manager writes all missing-permission messages. The value of the second argument is a file to which Printing Security Manager writes the missing policy grants.

For example, for a Windows system without a UNIX shell, add the argument to JAVA_OPTIONS: 

$ set JAVA_OPTIONS=-Djava.security.manager=weblogic.security.psm.PrintingSecurityManager
-Doracle.weblogic.security.manager.printing.file=psm_perms.txt

$ startWeblogic.cmd

If you do not specify the full path for the output files, they are created in DOMAIN_HOME.

Using Jakarta Authorization

Jakarta Authorization provides an alternate authorization mechanism for the EJB and servlet containers in a WebLogic Server domain. You can enable the WebLogic JACC provider by specifying certain system property-value pairs.

The Jakarta Authorization specification is part of the Jakarta EE Platform. Jakarta Authorization extends the Java permission-based security model to EJBs and servlets. Jakarta Authorization is defined at https://jakarta.ee/specifications/authorization/. Jakarta Authorization was previously known as Java Authorization Contract for Containers (JACC).

As shown in Table 7-2, when Jakarta Authorization 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 Jakarta Authorization provider which, although fully compliant with the Jakarta Authorization specification, is not as optimized as the WebLogic Authorization provider. The Jakarta Authorization classes are used for rendering access decisions. Because the Jakarta Authorization specification does not define how to address role mapping, WebLogic JACC classes are used for role-to-principal mapping.

Note:

The Jakarta Authorization classes used by WebLogic Server do not include an implementation of a Policy object for rendering decisions but instead rely on the java.security.Policy object (see Java SE and JDK API Specification ).

This section discusses the following topics:

Table 7-2 shows which providers are used for role mapping when JACC is enabled.

Table 7-1 When Jakarta Authorization is Enabled

Status Provider used for EJB/Servlet Authorization and Role Mapping Provider used for all other Authorization and Role Mapping EJB/Servlet Roles and Policies Can be Viewed and Modified by WebLogic Remote Console

Jakarta Authorization is enabled

JACC provider

WebLogic Security Framework providers

No

Jakarta Authorization is not enabled

WebLogic Security Framework providers

WebLogic Security Framework providers

Yes, depending on settings

Note:

In a domain, either enable Jakarta Authorization on all servers or on none. The reason is that Jakarta Authorization is server-specific, while the WebLogic Security Framework is realm/domain specific. If you enable Jakarta Authorization, either by using the WebLogic JACC provider or (recommended) by creating your own Jakarta Authorization provider, you are responsible for keeping EJB and servlet authorization policies synchronized across the domain. For example, applications are redeployed each time a server boots. If a server configured for Jakarta Authorization reboots without specifying the Jakarta Authorization options on the command line, the server uses the default WebLogic Authorization provider for EJB and servlet role mapping and authorization decisions.

Comparing the WebLogic JACC Provider with the WebLogic Authorization Provider

The WebLogic JACC provider fully complies with the Jakarta Authorization specification; 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 7-2 compares the features provided by the WebLogic JACC provider with those of the WebLogic Authorization provider.

Table 7-2 Comparing the WebLogic JACC Provider with the WebLogic Authorization Provider

WebLogic JACC Provider WebLogic Authorization Provider

Implements the Jakarta Authorization specification

Value-added security framework

Addresses only EJB and servlet deployment/authorization decisions

Addresses deployment/authorization decisions

Uses the java.security.Policy object to render decisions

Allows for multiple authorization/role providers

Static role mapping at deployment time

Dynamic role mapping

Jakarta EE permissions control access

Entitlements engine controls access

Role and role-to-principal mappings are modifiable only through deployment descriptors

Roles and role-to-principal mappings are modifiable through deployment descriptors and WebLogic Remote Console

Enabling the WebLogic JACC Provider

In the command that starts WebLogic Server, you can enable the WebLogic JACC provider by specifying the following system property/value pairs:

  • Property:

    jakarta.security.jacc.PolicyConfigurationFactory.provider

    Value:

    weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl

  • Property:

    jakarta.security.jacc.policy.provider

    Value:

    weblogic.security.jacc.simpleprovider.SimpleJACCPolicy

  • Property:

    weblogic.security.jacc.RoleMapperFactory.provider

    Value:

    weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

Note:

If the system properties, -Djakarta.security.jacc.PolicyConfigurationFactory.provider and -Djakarta.security.jacc.policy.provider are specified, then WebLogic Server automatically initializes the default RoleMapperFactory property. Therefore, you do not need to specify the weblogic.security.jacc.RoleMapperFactory.provider system property to enable the WebLogic JACC provider.

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

# ./startWebLogic.sh -Djakarta.security.jacc.policy.provider=\
weblogic.security.jacc.simpleprovider.SimpleJACCPolicy \
-Djakarta.security.jacc.PolicyConfigurationFactory.provider=\
weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl \