Set Java 2 security policy files


Users can configure Java2 security policy files so that the required permission is granted for the specified WAS enterprise application.

Java 2 security uses several policy files to determine the permissions for each Java programs. Two types of policy files are supported by WAS: dynamic policy files and static policy files. Static policy files provide the default permissions. Dynamic policy files provide application permissions. Six dynamic policy files are provided:


Table 1. Dynamic policy files

Policy file name Description
app.policy Contains default permissions for all of the enterprise apps in the cell.

Updates to the app.policy file only apply to the enterprise apps on the node to which the app.policy file belongs.

was.policy Contains application-specific permissions for an WAS enterprise application. This file is packaged in an EAR file.
ra.xml Contains connector application specific permissions for a WAS enterprise application. This file is packaged in a resource adapter archive (RAR) file.
spi.policy Contains permissions for Service Provider Interface (SPI) or third-party resources that are embedded in WAS. The default contents grant everything. Update this file carefully when the cell requires more protection against SPI in the cell. This file is applied to all of the SPIs defined in the resources.xml file.
library.policy Contains permissions for the shared library of enterprise apps.
filter.policy Contains the list of permissions that require filtering from was.policy and the app.policy file in the cell. This filtering mechanism only applies to the was.policy and app.policy files.

In WAS, applications must have the appropriate thread permissions specified in the was.policy or app.policy file. Without the thread permissions specified, the application cannot manipulate threads and WAS creates a java.security.AccessControlException exception. The app.policy file applies to a specified node. If we change the permissions in one app.policy file, incorporate the new thread policy in the same file on the remaining nodes.

If we add the thread permissions to the app.policy file, restart WAS to enforce the new permissions. However, if we add the permissions to was.policy for a specific application, you do not need to restart WAS. An administrator must add the following code to a was.policy or app.policy file for an application to manipulate threads:

grant codeBase "file:${application}" {
  permission java.lang.RuntimePermission "stopThread";
  permission java.lang.RuntimePermission "modifyThread";
  permission java.lang.RuntimePermission "modifyThreadGroup";
};

The Signed By keyword is not supported in the following policy files: app.policy, spi.policy, library.policy, was.policy, and filter.policy files. However, the Signed By keyword is supported in the following policy files:java.policy, server.policy, and client.policy files. The Java Authentication and Authorization Service (JAAS) is not supported in the app.policy, spi.policy, library.policy, was.policy, and filter.policy files. However, the JAAS principal keyword is supported in a JAAS policy file when it is specified by the java.security.auth.policy JVM system property. We can statically set the authorization policy files in java.security.auth.policy with auth.policy.url.n=URL, where URL is the location of the authorization policy.

 

  1. Identify the policy file to update.

    Tip: Pick up the policy file with the smallest scope. We can avoid giving an extra permission to the Java programs and protect the resources. We can update the ra.xml file or was.policy rather than the app.policy file. Use specific component symbols ($(ejbcomponent), ${webComponent},${connectorComponent} and ${jars}) than ${application} symbols. Update dynamic policy files, rather than static policy files.

    Add any permission that you never want granted to the WAS enterprise application in the cell to the filter.policy file. Refer to filter.policy file permissions.

  2. Restart the WAS enterprise application.

 

Results

The required permission is granted for the specified WAS enterprise application.

 

Example

If an WAS enterprise application in a cell requires permissions, some of the dynamic policy files need updating. The symptom of the missing permission is the java.security.AccessControlException exception. The missing permission is listed in the exception data, which will appear as one line, but is split in sections below for readability.

When a Java program receives this exception and adding this permission is justified, add a permission to an adequate dynamic policy file.

The previous permission information lines are split for the illustration. Enter the permission on one line.

To decide whether to add a permission, refer to the Access control exception topic.


app.policy file permissions
filter.policy file permissions
Set was.policy for Java 2 security
spi.policy file permissions
library.policy file permissions
Add was.policy to applications for Java 2 security

 

Related tasks


Migrating, coexisting, and interoperating – Security considerations
Set static policy files in Java 2 security
Protecting system resources and APIs (Java 2 security)