Dynamic Java 2 security policy files

 

Java 2 security uses several policy files to determine the granted permissions for each Java programs. 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 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 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 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.

The Signed By keyword is not supported in the following policy files:

app.policy, spi.policy, library.policy, was.policy, filter.policy

The Signed By keyword is supported in the following policy files:

java.policy, server.policy, client.policy

JAAS is not supported in

app.policy, spi.policy, library.policy, was.policy, filter.policy

The JAAS principal keyword is supported in a JAAS policy file when it is specified by the JVM property: java.security.auth.policy.

1. Identify the policy file to update.

   • If the permission is required by an application, update the static policy file.

   • If the permission is required by all of the WAS enterprise applications in the node, refer to Configuring spi.policy files.

   • If the permission is required only by specific WAS enterprise applications and the permission is required only by connector, update the ra.xml file. Refer to Assembling resource adapter (connector) modules. Otherwise, update the was.policy file. Refer to Configuring was.policy files and Adding the was.policy file to applications.

   • If the permission is required by shared libraries, refer to library.policy.

   • If the permission is required by SPI libraries, refer to spi.policy files.

   Note that It is recommended 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 WAS enterprise application in the cell to the filter.policy file. Refer to Configuring filter.policy files.

2. Restart the WAS enterprise application.

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

 

Usage Scenario

java.security.AccessControlException: access denied  java.io.FilePermission($WAS_HOME/java/jre/lib/ext/mail.jar read)

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 "$WAS_HOME/java/jre/lib/ext/mail.jar", "read";
};

To decide whether to add a permission, refer to the article AccessControlException.

 

---