Users can configure Java 2
security policy files so that the required permission is granted for
the specified WebSphere® Application Server enterprise
application.
Before you begin
Java 2 security uses several policy
files to determine the permissions for each Java programs.
See
the Java 2 security policy files topic for the list of available policy
files that are supported by WebSphere Application Server.
Two
types of policy files are 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. Six dynamic policy files are provided:
Table 1. Dynamic policy files. This table
lists the dynamic policy files.Policy file name |
Description |
app.policy |
Contains default permissions for
all of the enterprise applications in the cell. Note: Updates to the app.policy file only
apply to the enterprise applications on the node to which the app.policy file
belongs.
|
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 that are 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 that are 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
that are specified in the
was.policy or
app.policy file.
Without the thread permissions that are specified, the application
cannot manipulate threads and WebSphere Application Server
creates a java.security.AccessControlException exception. The
app.policy file
applies to a specified node. If you change the permissions in one
app.policy file,
you must 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,
you must 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.security.auth.policy Java virtual machine (JVM) system property.
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.
Procedure
- Identify the policy file to update.
Tip: 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,
rather than static policy files.
Add any permission that
you never want granted to the WebSphere Application Server
enterprise application in the cell to the filter.policy file.
Refer to filter.policy file permissions.
- Restart the WebSphere Application Server
enterprise application.
Results
The required permission is granted for the specified WebSphere Application Server enterprise
application.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Example
If an WebSphere Application
Server 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 appears
as one line, but is split in sections below for readability.
![[IBM i]](../images/iseries.gif)
java.security.AccessControlException: access denied (java.io.FilePermission
${was.install.root}/java/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.
![[IBM i]](../images/iseries.gif)
grant codeBase "file:user_client_installed_location" {
permission java.io.FilePermission
"${was.install.root}$(/)java$(/)jre$(/)lib$(/)ext$(/)mail.jar", "read";
};
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 for Java 2 security topic.