Configure Java 2 security policy files

 

Configure Java 2 security policy files

Java 2 security uses several policy files to determine the granted permissions for each Java programs. See the Java 2 security policy files article for the list of available policy files supported by WebSphere Application Server.There are two types of policy files supported by WebSphere Application Server: dynamic policy files and static policy files. Static policy files provide the default permissions. Dynamic policy files provide application permissions. There are six dynamic policy files:

Policy file name Description
app.policy Contains default permissions for all of the enterprise applications in the cell.
was.policy Contains application-specific permissions for an WebSphere Application Server enterprise application. This file is packaged in an enterprise archive (EAR) file.
ra.xml Contains connector application specific permissions for a WebSphere Application Server 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 embedded in WebSphere Application Server. 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 applications.
filter.policy Contains the list of permissions that require filtering from the was.policy file and the app.policy file in the cell. This filtering mechanism only applies to the was.policy and app.policy files.
In WebSphere Application Server,
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 WebSphere Application Server throws a java.security.AccessControlException. The app.policy file applies to a specified node. If you change the permissions in one app.policy file, incorporate the new thread policy in the same file on the remaining nodes. Also, if you add the thread permissions to the app.policy file, restart WebSphere Application Server to enforce the new permissions. However, if you add the permissions to the was.policy file for a specific application, you do not need to restart WebSphere Application Server. 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";
};

Important: 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 Virtual Machine (JVM) system property, java.security.auth.policy. You 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.

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

    Add any permission that should never be granted to the WebSphere Application Server enterprise application in the cell to the filter.policy file. Refer to Configuring filter.policy files.

  2. Restart the WebSphere Application Server enterprise application.

ResultThe required permission is granted for the specified WebSphere Application Server enterprise application.

Example

java.security.AccessControlException: access denied (java.io.FilePermission
/QIBM/ProdData/WebSphere/AppServer/V6/Base/java/jre/lib/ext/mail.jar read)

The previous two lines were split onto two lines because of the width of the page. However, the permission should be on one line. When a Java program receives this exception and adding this permission is justified, add a permission to an adequate dynamic policy file, for example,

grant codeBase "file:<user client installed location>" {
permission java.io.FilePermission
"/QIBM/ProdData/WebSphere/AppServer/V6/Base/java/jre/lib/ext/mail.jar", "read";
};

The previous two lines were split onto two lines because of the width of the page. However, the permission should be on one line.

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


Sub-topics
Configuring app.policy files
Configuring filter.policy files
Configuring the was.policy file
Configuring spi.policy files
Configuring library.policy files
Adding the was.policy file to applications

Related concepts
Java 2 security policy files
Access control exception

Related tasks
Migrating security configurations from previous releases
Configuring static policy files

Related reference
Java 2 security