+

Search Tips   |   Advanced Search

Configure the was.policy file for Java 2 security

We should update the was.policy file if the application has specific resources to access.

Java 2 security uses several policy files to determine the granted permission for each Java program. The was.policy file is an application-specific policy file for WebSphere Application Server enterprise applications. This file is embedded in the META-INF/was.policy enterprise archive (.EAR) file. The was.policy file is located in: 

 profile_root/config/cells/cell/applications/
ear_file_name/deployments/application_name/META-INF/was.policy

See Java 2 security policy files for the list of available policy files supported by WAS v6.1.

The union of the permissions contained in the following files is applied to the WAS enterprise application:

Changes made in these files are replicated to other nodes in the cell.

Symbol Definition
file:${application} Permissions apply to all resources used within the application.
file:${jars} Permissions apply to all utility JAR files within the application
file:${ejbComponent} Permissions apply to enterprise bean resources within the application
file:${webComponent} Permissions apply to web resources within the application
file:${connectorComponent} Permissions apply to connector resources within the application

In WAS, applications that manipulate threads 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. If we add the permissions to the was.policy file for a specific application, we 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";
};
An administrator can add the thread permissions to the app.policy file, but the permission change requires a restart of WAS.

Important: The Signed By and the JAAS principal keywords are not supported in the was.policy file. The Signed By keyword is supported in the java.policy, server.policy, and client.policy policy file. 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 the java.security.auth.policy file with the auth.policy.url.n=URL, where URL is the location of the authorization policy.

Other than these blocks, we can specify the module name for granular settings. For example, 

grant codeBase "file:DefaultWebApplication.war" {
  permission java.security.SecurityPermission "printIdentity";
};

grant codeBase "file:IncCMP11.jar" {
  permission java.io.FilePermission 
      "${user.install.root}${/}bin${/}DefaultDB${/}-", 
      "read,write,delete";
};

Symbol Definition
${app.installed.path} Path where the application is installed
${was.module.path} Path where the module is installed
${current.cell.name} Current cell name
${current.node.name} Current node name
${current.server.name} Current server name

If the default permissions for the enterprise application are enough, an action is not required. The default permissions are a union of the permissions defined in the java.policy file, the server.policy file, and the app.policy file. If an application has specific resources to access, update the was.policy file. The first two steps assume that we are creating a new policy file.

Tip: Syntax errors in the policy files cause the application server to fail. Use care when editing these policy files.


Tasks

  1. Create or edit a new was.policy file using the PolicyTool. See Use PolicyTool to edit policy files for Java 2 security.
  2. Package the was.policy file into the EAR file.

    See Add the was.policy file to applications for Java 2 security.

    The following instructions describe how to import a was.policy file.

    1. Import the EAR file into an assembly tool.

    2. Open the Project Navigator view.

    3. Expand the EAR file and click META-INF. We might find a was.policy file in the META-INF directory. To delete the file, right-click the file name and select Delete.

    4. In the Project Navigator view, click J2EE Hierarchy.
    5. Import the was.policy file by right-clicking the Modules directory within the deployment descriptor and by clicking Import > Import > File system.

    6. Click Next.

    7. Enter the path name to the was.policy file in the From directory field or click Browse to locate the file.

    8. Verify that the path directory listed in the Into directory field lists the correct META-INF directory.

    9. Click Finish.

    10. To validate the EAR file, right-click the EAR file, which contains the Modules directory, and click Run Validation.

    11. To save the new EAR file, right-click the EAR file, and click Export > Export EAR file. If we do not save the revised EAR file, the EAR file will contain the new was.policy file. However, if the workspace becomes corrupted, we might lose the revised EAR file.

    12. To generate deployment code, right-click the EAR file and click Generate Deployment Code.

  3. Update an existing installed application, if one already exists. Modify the was.policy file with the Policy Tool. See Use PolicyTool to edit policy files for Java 2 security.(ZOS)

    1. Extract the policy file. Enter the following command from a command prompt: 
      wsadmin> set obj [$AdminConfig extract profiles/profile/cells/cell
/application/ear_file_name/deployments/application_name
/META_INF/was.policy c:/temp/test/was.policy]

      Enter the three previous lines as one continuous line. They are display here for illustration only.

    2. Edit the extracted was.policy file with the Policy Tool. See Use PolicyTool to edit policy files for Java 2 security.

    3. Check in the policy file. Enter the following at a command prompt: 
      wsadmin> $AdminConfig checkin profiles/profile/cells/cell/application/
ear_file_name/deployments/application_name/META_INF/was.policy 
c:/temp/test/was.policy $obj

      Enter the three previous lines as one continuous line. They are display here for illustration only.

The updated was.policy file is applied to the application after the application restarts.


Example

(iSeries) (ZOS) 
java.security.AccessControlException: access denied (java.io.FilePermission 
${was.install.root}/java/ext/mail.jar read)

(ZOS) (iSeries) If an application must access a specific resource that is not defined as a default in the java.policy file, the server.policy file, and the app.policy, delete the was.policy file for that application. The symptom of the missing permission is the java.security.AccessControlException exception. The missing permission is listed in the exception data:

The following examples are split into several lines for illustration only. You actually enter the permission on one line. (iSeries) (ZOS) 

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 the following permission to the was.policy file:

(iSeries) (ZOS) 
grant codeBase "file:user_client_installed_location" { 
  permission java.io.FilePermission 
"${was.install.root}$(/)java$(/)jre$(/)lib$(/)ext$(/)mail.jar", "read";
};

To determine whether to add a permission, see Access control exception for Java 2 security.


What to do next

Restart all applications for the updated app.policy file to take effect.


Related:

  • Access control exception for Java 2 security
  • Configure Java 2 security policy files
  • Migrate, coexist, and interoperate - Security considerations
  • Add the was.policy file to applications for Java 2 security
  • Java 2 security policy files
  • spi.policy file permissions
  • library.policy file permissions