+

Search Tips   |   Advanced Search

Protecting system resources and APIs (Java 2 security) for developing applications

Java 2 security is a programming model that is very pervasive and has a huge impact on application development.

Java 2 security is orthogonal to Java EE role-based security; we can disable or enable it independently of administrative security.

However, it does provide an extra level of access control protection on top of the Java EE role-based authorization. It particularly addresses the protection of system resources and APIs. Administrators must 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. Developers must know whether 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 website for Development Kit APIs that are protected by Java 2 security. See the Programming model and decisions section of the Security: Resources for Learning topic to visit this website.

  2. Make sure that migrated applications from previous releases are given the required permissions. Because Java 2 security is not supported or partially supported in previous WebSphere Application Server releases, applications developed before Version 5 most likely are not using the Java 2 security programming model. No easy way to find out all the required permissions for the application is available. The following are activities that we 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 that is enabled in a preproduction 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 debugging. Do not use this property in a production environment.

      Refer to Java 2 security

(dist)(zos) The default permission set for applications is the recommended permission set defined in the J2EE 1.3 Specification. The default is declared in the app_server_root/profiles/profile_name/config/cells/cell_name/nodes/node/app.policy policy file with permissions defined in the Development Kit (JAVA_HOME/jre/lib/security/java.policy) policy file that grant permissions to everyone. However, applications are denied permissions that are declared in the profiles/profile_name/config/cells/cell_name/filter.policy file. Permissions that are declared in the filter.policy file are filtered for applications during the permission check.

(iseries) The default permission set for applications is the recommended permission set defined in the J2EE 1.3 Specification. The default is declared in the profile_root/config/cells/cell_name/nodes/node/app.policy policy file with permissions defined in the Development Kit policy file that grants permissions to everyone. The java.policy file is located in the java_home directory depending on the JVM that is enabled for the profile.

Only Java SE 6 has a JRE.(for example, /QOpenSys/QIBM/ProdData/JavaVM/jdk60/32bit/jre/lib/ext). For all Java virtual machines, the java.policy file is used system-wide. Do not edit the java.policy file on the server. Applications are denied permissions that are declared in the profile_root/config/cells/cell_name/filter.policy file. Permissions declared in the filter.policy file are filtered for applications during the permission check.

(iseries) Use the showVariables command of the AdminTask object to retrieve JAVA_HOME for the node associated with the server's profile. For example, if the node is myNode:

  1. Enter QShell.

  2. cd to profile_root/bin

  3. Run the following command:

      wsadmin -conntype NONE -c '$AdminTask showVariables {-scope Node=myNode -variableName JAVA_HOME}'

Define the required permissions for an application in a was.policy file and embed the was.policy file in the application EAR file as YOURAPP.ear/META-INF/was.policy, see Configure Java 2 security policy files for details.

The following steps describe how to enforce Java 2 security on the cell level for WebSphere Application Server Network Deployment and the server level for WebSphere Application Server Express

  1. Click Security > Global security. The Global security panel is displayed.

  2. Select the Use Java 2 security to restrict application access to local resources option.

  3. Click OK or Apply.

  4. Click Save to save the changes.

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


Results

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


When to use Java 2 security

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

  2. Prevent application code from calling destructive APIs, for example, calling the System.exit method brings down the application server.

  3. Prevent application code from obtaining privileged information (passwords) or gaining extra privileges (obtaining server credentials).


What to do next

We can enforce Java 2 security on the server level for WebSphere Application Server Network Deployment by completing the following steps.

Changes to Java 2 security settings on the server level override the settings on the cell level.

  1. Click Servers > Application servers > server_name.

  2. Under Security, click Server security.

  3. Select the Security settings for this server override cell settings option.

  4. Select the Use Java 2 security to restrict application access to local resources option.

  5. Click OK or Apply.

  6. Click Save to save the changes.

  7. Restart the server for the changes to take effect.
The Java 2 security manager is enhanced to dump the Java 2 security permissions that are granted to all classes on the call stack when an application is denied access to a resource. The java.security.AccessControlException exception is created. However, this tracing capability is disabled by default. We can enable this capability by specifying the server trace service with the com.ibm.ws.security.core.SecurityManager=all=enabled trace specification. When the exception is created, the trace dump provides hints to determine whether the application is missing permissions or the product runtime code or the third-party libraries used are not properly marked as privileged when accessing Java 2 security-protected resources.

See the Security Problem Determination Guide for details.


Subtopics


Related tasks

  • Develop applications that use programmatic security
  • Migrate Java 2 security policy
  • Migrate, coexist, and interoperate - Security considerations

  • Security: Resources for learning