Configure Java 2 security

 

Overview

Java 2 security is disabled by default, but is enabled automatically when global security is enabled. However, Java 2 security is orthogonal to J2EE role-based security; you can disable or enable it independently of Global Security.

Java 2 security provides an extra level of access control protection on top of J2EE role-based authorization. It particularly addresses the protection of system resources and APIs. Administrators should need to consider the benefits against the risks of disabling Java 2 Security.

The following recommendations are provided to help enable Java 2 security in a test or production environment:

  1. Make sure the application is developed with the Java 2 security programming model in mind. Developers have to know whether or not the APIs used in the applications are protected by Java 2 security. It is very important that the required permissions for the APIs used are declared in the policy file (was.policy), or the application fails to run when Java 2 security is enabled. Developers can reference the Web site for Development Kit APIs that are protected by Java 2 security. See the Programming model and decisions section of the Security: Resources for learning article to visit this Web site.

  2. Make sure that migrated applications from previous releases are given the required permissions. Since Java 2 security is not supported or partially supported in previous WebSphere Application Server releases, applications developed prior to V5 most likely are not using the Java 2 security programming model. There is no easy way to find out all the required permissions for the application. Following are activities you can perform to determine the extra permissions required by an application:

    • Code review and code inspection

    • Application documentation review

    • Sandbox testing of migrated enterprise applications with Java 2 security enabled in a pre-production environment. Enable tracing in WebSphere Java 2 security manager to help determine the missing permissions in the application policy file. The trace specification is com.ibm.ws.security.core.SecurityManager=all=enabled.

    • Use the com.ibm.websphere.java2secman.norethrow system property to aid debuggging. This property should not be used in a production environment. Refer to Java 2 security.

Note that the default permission set for applications is the recommended permission set defined in the J2EE 1.3 Specification. The default is declared in...

config/cells/<cell>/nodes/<node>/app.policy policy

...with permissions defined in the Development Kit policy file...

${JAVA_HOME}/lib/security/java.policy

...that grant permissions to everyone. However, applications are denied permissions declared in...

config/cells/cell/filter.policy

Permissions declared in the filter.policy file are filtered for applications during the permission check.

Define the required permissions for an application in a was.policy file and embed the was.policy file in the EAR file as...

YOURAPP.ear/META-INF/was.policy

 

Enable or disable Java 2 Security for the cell

 

Steps for this task

  1. Click...

    Security | Global Security

  2. Enable Java 2 Security by selecting the check box labeled Enforce Java 2 Security (clear the check box to disable Java 2 Security). This enables Java 2 Security for the cell.

  3. Click OK or Apply on the Global Security page.

  4. Save the changes and make sure a file sync is performed before restarting the servers.

  5. For the changes to take effect, restart all the servers, which include the Network Deployment Manager, all Node Agents, and all application servers.

 

Enable or disable Java 2 Security for an appserver

 

Steps for this task

  1. Click...

    Server | Application Servers | appserver | Server Security | Server Level Security

  2. Enable Java 2 Security by selecting the option labeled Enforce Java 2 Security (clear the check box to disable Java 2 Security). This enables Java 2 Security for the selected appserver.

  3. Click OK or Apply on the Server Level Security page.

  4. Save the changes and make sure a file sync is performed before restarting the appserver.

  5. Restart the appserver for the changes to take effect.

 

Results

Java 2 Security is enabled and enforced for the servers. Java 2 Security permission is checked when a Java 2 Security protected API is called.

When to use Java 2 Security

  1. To enable protection on system resources. For example, when opening or listening to a socket connection, reading or writing to operating system file systems, reading or writing Java Virtual Machine system properties, and so on.

  2. To prevent application code calling destructive APIs. For example, calling System.exit() brings down the appserver.

  3. To prevent application code obtaining privileged information (passwords) or gaining extra privileges (obtaining Server Credentials).

 

What to do next

The WebSphere Java 2 Security Manager is enhanced to dump the Java 2 Security permissions granted to all classes on the call stack when an application is denied access to a resource (the java.security.AccessControlException exception is thrown). The trace information is dumped to the configured server log files. Check the server log files to access debugging information when an AccessControlException is thrown. In addition, the product Java 2 Security Manager trace can be enabled with the trace string, com.ibm.ws.security.core.SecurityManager=all=enabled. When the exception is thrown, the trace dump provides hints to determine whether the application is missing permissions or the product run time code or third party libraries used are not properly marked as privileged when accessing Java 2 protected resources. See the Security Problem Determination Guide for details.
Related tasks
Migrating security configurations from previous releases