Why and when to perform this task
Previous WebSphere Application Server releases
WebSphere Application Server uses the Java 2 security manager in the server run time to prevent enterprise applications from calling the System.exit() and the System.setSecurityManager() methods. These two Java application programming interfaces (API) have undesirable consequences if called by enterprise applications. The System.exit() API, for example, causes the Java virtual machine (application server process) to exit prematurely, which is an undesirable operation for an application server.
To support Java 2 security properly, all the server run time must be marked as privileged (with doPrivileged() API calls inserted in the correct places), and identify the default permission sets or policy. Application code is not privileged and subject to the permissions defined in the policy files. The doPrivileged instrumentation is important and necessary to support Java 2 security. Without it, the application code must be granted the permissions required by the server run time. This is due to the design and algorithm used by Java 2 security to enforce permission checks. Please refer to the Java 2 security check permission algorithm.
Application code is denied access to these permissions regardless of what is in the Java 2 security policy. However, the server run time is granted these permissions. All the other permission checks are not enforced.
However, not all the product server run time is properly marked as privileged. You must grant the application code all the other permissions besides the two listed previously or the enterprise application can potentially fail to run. This Java 2 security policy for enterprise applications is liberal.
What changed
Java 2 Security is fully supported in WebSphere Application Server Version 6.0.x, which means all permissions are enforced. The default Java 2 security policy for enterprise application is the recommended permission set defined by the Java 2 Platform, Enterprise Edition (J2EE) Version 1.4 specification. Refer to the install_root/profiles/profile_name/config/cells/cell_name/nodes/node_name/app.policy file for the default Java 2 security policy granted to enterprise applications. This policy is a much more stringent compared to previous releases.
All policy is declarative. The product security manager honors all policy declared in the policy files. There is an exception to this rule: enterprise applications are denied access to permissions declared in the install_root/profiles/profile_name/config/cells/cell_name/filter.policy file.
In application code, do not use the setSecurityManager permission to set a security manager. When an application uses the setSecurityManager permission, there is a conflict with the internal security manager within WebSphere Application Server. If you must set a security manager in an application for RMI purposes, you also must enable the Enforce Java 2 Security option on the Global security settings page within the WebSphere Application Server administrative console. WebSphere Application Server then registers a security manager. The application code can verify that this security manager is registered by using System.getSecurityManager() application programming interface (API).
Migrating system properties
Migrating the Java 2 Security Policy
There is no easy way of migrating the Java policy file to WebSphere Application Server Version 6.0.x automatically because there is a mixture of system permissions and application permissions in the same policy file. Manually copy the Java 2 security policy for enterprise applications to a was.policy or app.policy file. However, migrating the Java 2 security policy to a was.policy file is preferable because symbols or relative codebase is used instead of absolute codebase. There are many advantages to this process. The permissions defined in the was.policy file should only be granted to the specific enterprise application, while permissions in the app.policy file apply to all the enterprise applications running on the node where the app.policy file belongs. Refer to the Java 2 security policy files article for more details on policy management.
The following example illustrates the migration of a Java 2 security policy from a previous release. The contents include the Java 2 security policy file for the app1.ear enterprise application and the system permissions, which are permissions granted to the Java virtual machine (JVM) and the product server run time. The default location for the Java 2 security policy file is install_root/profiles/profile_name/properties/java.policy. Default permissions are omitted for clarity:
The following example illustrates the migration of a Java 2 security policy from a previous release. The contents include the Java 2 security policy file for the app1.ear enterprise application and the system permissions, which are permissions granted to the Java virtual machine (JVM) and the product server run time. The default location for the Java 2 security policy file is profile_root/profiles/profile_name/properties/java.policy. Default permissions are omitted for clarity:
// For product Samples grant codeBase "file:${install_root}/installedApps/app1.ear/-" { permission java.security.SecurityPermission "printIdentity"; permission java.io.FilePermission "${install_root}${/}temp${/}somefile.txt", "read"; };
For clarity of illustration, all the permissions are migrated as the application level permissions in this example. However, you can grant permissions at a more granular level at the component level (Web, enterprise beans, connector or utility Java archive (JAR) component level) or you can grant permissions to a particular component.
Steps for this task
grant codeBase "file:${application}" {
permission java.security.SecurityPermission "printIdentity";
permission java.io.FilePermission "
${user.install.root}${/}temp${/}somefile.txt", "read";
};
The third and fourth lines in the previous code sample are split into two lines for illustrative purposes only.
The was.policy file is located in the profiles/profile_name/config/cells/cell_name/applications/app.ear/deployments/app/META-INF/ directory.