Use Java 2 security with WebSphere Portal

 

+

Search Tips   |   Advanced Search

 

Overview

Java 2 (J2SE) security provides a policy-based, fine-grain access control mechanism that increases overall system integrity by checking for permissions before allowing access to certain protected system resources. J2SE security allows you to set up individual policy files that control the privileges assigned to individual code sources.

If code does not have the required permissions and still tries to execute a protected operation, a corresponding security exception will be thrown by the Java Access Controller.

The assignment of individual permissions to individual code sources is done via policy files. The syntax and semantics of those files is defined in the Java Language Specification. WebSphere Application Server uses a specific set of policy files to set up Java 2 Security.

Here are the policy files and their scope:

$WAS_HOME/java/jre/lib/security/java.policy

Root policy file containing permissions for all code that is executed on the corresponding JVM

$WAS_HOME/properties/server.policy

Default permissions granted to all product servers

$WAS_HOME/config/cells/cell/nodes/node/library.policy

Default permissions granted to code contained in the shared library

$WAS_HOME/config/cells/cell/nodes/node/app.policy

Default permissions for all enterprise applications running on this node

$WAS_HOME/config/cells/cell/applications/ear_file/deployments/app/META-INF/was.policy

Permissions assigned to a specific enterprise application

All WebSphere Portal code has the the java.security.AllPermission specified in the server.policy file and all was.policy files that ship with the product. doPrivileged() calls are introduced into the portlet API to provide a portlet sandbox.

Java 2 security can be enabled/disabled using the WebSphere Application Server administration facilities. Java 2 security is independent from J2EE security so you can enable Java 2 security independently from enabling Global Security on the server instance.

Notes:

  • The was.policy for a portlet application WAR file should be placed in the appname.war/META-INF directory prior to packaging the portlet. See Creating a simple portlet for more information.

  • The was.policy file is moved from the war/META-INF directory to the ear/META-INF directory during portlet deployment. To modify the permissions of an installed portlet after it has been deployed, modify the was.policy file within the ear/META-INF directory.

  • The existing was.policy file is overwritten when a portlet is redeployed. To preserve the contents of the was.policy file during redeployment, follow these steps:

    1. Make a backup copy of the was.policy file.
    2. Redeploy the portlet.
    3. Overwrite the redeployed was.policy file with the backup copy of the file.

  • For applications built with the Struts Portlet Framework or Click-to-Action, a was.policy file must be placed in the META-INF directory. Here are three examples of was.policy files. In Example 1, the file grants full access to the code contained in the portlet application. Example two shows a was.policy file that implements a more restrictive approach. Example three shows the minimum requirement for the Struts Portlet Framework.

    Example 1: Full access 

      //
  // Template policy file for enterprise application.
  // Extra permissions can be added if required by the enterprise 
  // application.   
  //
  // NOTE: Syntax errors in the policy files will cause the enterprise 
  // application FAIL to start. Extreme care should be taken when editing 
  //  these policy files. It is advised to use the policytool provided
  //  by the JDK for editing the policy files
  //  (WAS_HOME/java/jre/bin/policytool). 
  //

  grant codeBase "file:${application}" {
   permission java.security.AllPermission;
  };

    Example 2: Restricted access 

      //
  // Template policy file for enterprise application.
  // Extra permissions can be added if required by the enterprise 
  // application.   
  //
  // NOTE: Syntax errors in the policy files will cause the enterprise 
  // application FAIL to start. Extreme care should be taken when editing 
  //  these policy files. It is advised to use the policytool provided
  //  by the JDK for editing the policy files
  //  (WAS_HOME/java/jre/bin/policytool). 
  //

  grant codeBase "file:${application}" {

  // Allow the portlet to read/write system properties
  permission java.util.PropertyPermission "*", "read,write";

  // Allow the portlet to read arbitrary files from disk
  permission java.io.FilePermission "<<ALL FILES>>", "read";
  };

    Example 3: Minimum requirement for Struts Portlet Framework 

    grant codeBase "file:${application}" {
   permission java.util.PropertyPermission "user.language", "read, write";
   permission java.util.PropertyPermission "org.apache.commons.logging.LogFactory", "read";
   permission java.lang.RuntimePermission "accessDeclaredMembers";

   // The following permission (specifically the delete permission)
   // allows the FileUpload example to function, since it must be
   // able to delete temporary files.  You should probably comment
   // this out if your application does not need it.  At the least,
   // consider limiting the permission granted to specific files or
   // directories.
   permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";
};

  • Information on exceptions that are indications of missing Java 2 Permissions can be found in the WebSphere Application Server Information Center in the Welcome To Security - Java 2 Security - AccessControlException section.

 

See also

 

WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.

 

IBM is a trademark of the IBM Corporation in the United States, other countries, or both.