Before you begin
Java 2 security uses several policy files to determine the granted permission for each Java program. See Java 2 security policy files for the list of available policy files supported by WebSphere Application Server Version 5. The was.policy file is an application-specific policy file for WebSphere Application Server enterprise applications. It is embedded in the enterprise archive (EAR) file (META-INF/was.policy). The was.policy file is located in:install_root/config/cells/cell_name/applications/ ear_file_name/deployments/application_name/META-INF/was.policy
The union of the permission contained in the java.policy file, the server.policy file, the app.policy file, application was.policy file and the permission specification of the ra.xml file are applied to the WebSphere Application Server enterprise application. Configuration and file replication services manage was.policy files. Changes made in these files are replicated to other nodes in the Network Deployment cell.
Several product-reserved symbols are defined to associate the permission lists to a specific type of resources.
Symbol | Definition |
---|---|
file:${application} | file:${application} |
file:${jars} | Permissions apply to all utility Java archive (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 |
Note: The Signed By and the Java Authentication and Authorization Service (JAAS) principal keywords are not supported in the was.policy file. The Signed By keyword is supported in the following policy files: java.policy, server.policy, and client.policy. 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.
Other than these blocks, you can specify the module name for granular settings. For example,
"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"; };
There are five embedded symbols provided to specify the path and name for the java.io.FilePermission. These symbols enable flexible permission specification. The absolute file path is fixed after the application is installed.
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 |
Why and when to perform this task
If the default permissions for the enterprise application (union of the permissions defined in the java.policy file, the server.policy file and the app.policy file) are enough, no action is required. If an application has specific resources to access, update the was.policy file. The first two steps assume that you are creating a new policy file.Note: Syntax errors in the policy files cause the application server to fail. Use care when editing these policy files.
Steps for this task
For more information, see Adding the was.policy file to applications.
The following instructions describe how to import a was.policy file. However, you also can use the Assembly Toolkit to create a new file by clicking File > New > File.Results
The updated was.policy file is applied to the application after the application restarts.Example
java.policyserver.policyapp.policywas.policyjava.security.AccessControlExceptionjava.security.AccessControlException: access denied (java.io.FilePermission C:\WebSphere\AppServer\java\jre\lib\ext\mail.jar read)When a Java program receives this exception and adding this permission is justified, add a permission to the was.policy file: grant codeBase "file:<user client installed location>" { permission java.io.FilePermission "C:\WebSphere\AppServer\java\jre\lib\ext\mail.jar", "read"; };.
To determine whether to add a permission, refer to the article, AccessControlException.
What to do next
Restart all applications for the updated app.policy file to take effect.