Java 2 security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. Java 2 security guards access to system resources such as file I/O, sockets, and properties. Java 2 Platform, Enterprise Edition (J2EE) security guards access to Web resources such as servlets, JavaServer Pages (JSP) files and Enterprise JavaBeans (EJB) methods. WebSphere global security includes J2EE role-based authorization, the Common Secure Interoperability Version 2 (CSIv2) authentication protocol, and Secure Sockets Layer (SSL) configuration.
Because Java 2 security is relatively new, many existing or even new applications might not be prepared for the very fine-grain access control programming model that Java 2 security is capable of enforcing. Administrators must understand the possible consequences of enabling Java 2 security if applications are not prepared for Java 2 security. Java 2 security places some new requirements on application developers and administrators.
Java 2 security for deployers and administrators
Although Java 2 security is supported , it is disabled by default. However, it is enabled automatically if you also enable global security when configuring security. Although it becomes enabled automatically when you enable WebSphere global security, you can choose to disable it. You can configure Java 2 security and global security independently of one another. Disabling global security does not disable Java 2 security automatically. You need to explicitly disable it.
If your applications, or third-party libraries are not ready, having Java 2 security enabled causes problems. You can identify these problems as Java 2 security AccessControlExceptions in the system log or trace files. If you are unsure about the Java 2 security readiness of your applications, disable Java 2 security initially to get your application installed and verify that it is working properly.
If an application is not prepared for Java 2 security, if the application provider does not provide a was.policy file as part of the application, or if the application provider does not communicate the expected permissions the application is likely to cause Java 2 security access control exceptions at run time. It might not be obvious that an application is not prepared for Java 2 security. Several run-time debugging aids help troubleshoot applications that might have access control exceptions. See the Java 2 security debugging aids for more details. See Handling applications that are not Java 2 security ready for information and strategies for dealing with such applications.
It is important to note that when Java 2 Security is enabled in the Global Security settings, the installed SecurityManager does not currently check modifyThread and modifyThreadGroup permissions for non-system threads. Allowing Web and EJB application code to create or modify a thread can have a negative impact on other components of the container and can affect the capability of the container to manage enterprise bean life cycles and transactions.
Java 2 security for application developers
Application developers must understand the permissions granted in the default WebSphere policy and the permission requirements of the SDK APIs that their application calls to know whether additional permissions are required. The "Permissions in the Java 2 SDK" reference in the resources section describes which APIs require which permission.
Application providers can assume that applications have the permissions granted in the default policy previously mentioned. Applications that access resources not covered by the default WebSphere policy are required to grant the additional Java 2 security permissions to the application.
While it is possible to grant the application additional permissions in one of the other dynamic WebSphere policy files or in one of the more traditional static policy files, such as java.policy, the was.policy (which is embedded in the EAR file) ensures the additional permissions are scoped to the exact application that requires them. Scoping the permission beyond the application code that requires it can permit code that normally does not have permission to access particular resources.
If an application component is being developed, like a library that might actually be included in more than one .ear file, then the library developer should document the required Java 2 permissions needed by the application assembler. There is no was.policy file for library type components. The developer must communicate the required permissions through application programming interface (API) documentation or some other external documentation.
If the component library is shared by multiple enterprise applications, the permissions can be granted to all enterprise applications on the node in the app.policy file.
If the permission is only used internally by the component library and the application should never be granted access to resources protected by the permission, then it might be necessary to mark the code as privileged (inserting doPrivileged). Refer to the article, AccessControlException, for more details. However, improperly inserting a doPrivileged might open up security holes. Understand the implication of doPrivileged to make a correct judgement whether a doPrivileged should be inserted or not.
The section on Dynamic Policy describes how the permissions in the was.policy files are granted at run time.
Developing an application with Java 2 security in mind might be a new skill and impose a security awareness not previously required of application developers. Describing the Java 2 security model and the implications on application development is beyond the scope of this section. The following URL can help you get started: http://java.sun.com/j2se/1.3/docs/guide/security/index.html.
Debugging Aids
There are two primary aids, the WebSphere SystemOut.log file and the com.ibm.websphere.java2secman.norethrow property.The WebSphere System Log or Trace Files
The AccessControl exception logged in the system log or trace files contains the permission violation that causes the exception, the exception call stack, and the permissions granted to each stack frame. This information is usually enough to determine the missing permission and the code requiring the permission.The com.ibm.websphere.java2secman.norethrow Property
When Java 2 security is enabled in WebSphere Application Server, the security manager component throws a java.security.AccessControl exception when a permission violation occurs. This exception, if not handled, often causes a run-time failure. This exception is also logged in the SystemOut.log file.However, when the JVM com.ibm.websphere.java2secman.norethrow property is set and has a value of true, the security manager does not throw the AccessControl exception. This information is logged.
To set the com.ibm.websphere.java2secman.norethrow property for the server, go to the WebSphere Application Server administrative console and click Servers > Application Servers. Under Additional Properties, click Process Definition > Java Virtual Machine > Custom Properties > New. In the Name field, type com.ibm.websphere.java2secman.norethrow. In the Value field, type true.
To set the com.ibm.websphere.java2secman.norethrow property for the node agent, go to the WebSphere Application Server administrative console and click System Administration > Node Agents. Under Additional Properties, click Process Definition > Java Virtual Machine > Custom Properties > New. In the Name field, type com.ibm.websphere.java2secman.norethrow. In the Value field, type true.
This property is valuable in a sandbox or test environment where the application can be thoroughly tested and where the system log or trace files can be inspected for AccessControl exceptions. Since this property does not throw the AccessControl exception , it does not propagate the call stack and does not cause a failure. Without this property, you have to find and fix AccessControl exceptions one at a time.
Handling applications that are not Java 2 security ready
If the increased system integrity that Java 2 security provides is important, then contact the application provider to have the application support Java 2 security or at least communicate the required additional permissions beyond the default WebSphere policy that must be granted.The easiest way to deal with such applications is to disable Java 2 security in WebSphere Application Server. The downside is that this solution applies to the entire system and the integrity of the system is not as strong as it might be. Disabling Java 2 security might not be acceptable depending on the organization security policies or risk tolerances.
grant codeBase "file:${application}" {
permission java.security.AllPermission;
};
The server.policy file
The server.policy file is located in the install_root/properties/ directory.
This policy defines the policy for the WebSphere classes. At present, all the server processes on the same installation share the same server.policy file. However, you can configure this file so that each server process can have a separate server.policy file. Define the desired policy file as the value of the Java system properties java.security.policy. For details of how to define Java system properties, Refer to the Process definition section of the Manage application servers file.
The server.policy file is not a configuration file managed by the repository and the file replication service. Changes to this file are local and do not get replicated to other machines. Use the server.policy file to define Java 2 security policy for server resources. Use the app.policy file (per node) or was.policy file (per enterprise application) to define Java 2 security policy for enterprise application resources.
The java.policy file
The file represents the default permissions granted to all classes. The policy of this file applies to all the processes launched by the Java Virtual Machine (JVM) in WebSphere Application Server.
The java.policy file is located in the WAS_HOME/java/jre/lib/security directory.
Troubleshooting
Symptom:
Error message CWSCJ0314E: Current Java 2 security policy reported a potential violation of Java 2 security permission. Refer to Problem Determination Guide for further information.{0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5} Current Java 2 security policy reported a potential violation of Java 2 Security Permission. Refer to Problem Determination Guide for further information.{0}Permission\:{1}Code\:{2}{3}Stack Trace\:{4}Code Base Location\:{5}
Problem:
The Java security manager checkPermission() reported a SecurityException on the subject permission with debugging information. The reported information can be different with respect to the system configuration. This report is enabled by either configuring RAS trace into debug mode or specifying a Java property.
See Enabling trace for information on how to configure RAS trace in debug mode.
Recommended response:
permission java.io.FilePermission "${user.home}${/}.mailcap", "read";
permission java.io.FilePermission "${user.home}${/}.mime.types", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mailcap", "read";
permission java.io.FilePermission "${java.home}${/}lib${/}mime.types", "read";
Messages
Message: | CWSCJ0313E: Java 2 security manager debug message flags are initialized\: TrDebug: {0}, Access: {1}, Stack: {2}, Failure: {3} |
Problem: | Configured values of the valid debug message flags for security manager. |
Recommended response: | None. |
Message: | CWSCJ0307E: Unexpected exception is caught when trying to determine the code base location. Exception: {0} |
Problem: | An unexpected exception is caught when the code base location is determined. |
Recommended response: | Contact an IBM representative. |
Related concepts
Enabling tracing and logging
Related reference
Java 2 Connector authentication data entry settings
Configuration entry settings for Java Authentication and Authorization
Service
Login module settings for Java Authentication and Authorization Service