Portal Express, Version 6.0
Operating systems: i5/OS, Linux, Windows

---

 

Use Java 2 security with WebSphere Portal Express

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 the 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. Refer to the WebSphere Application Server information center for a complete discussion of all policy files used by WebSphere Application Server.

The following table contains information on the policy files and their protection scope:

File	Default Location	Description
java.policy	app_server_root/java/jre/lib/security/java.policy	Root policy file containing permissions for all the processes launched by WebSphere Application Server.
server.policy	WebSphere Application Server: was_profile_root/properties/server.policy	Default permissions granted to all product servers.
client.policy	WebSphere Application Server: was_profile_root/properties/client.policy	Default permissions for all of the product client containers and applets on a node.
spi.policy	WebSphere Application Server: was_profile_root/config/cells/cell/nodes/node/spi.policy	This template is for the Service Provider Interface (SPI) or the third party resources that are embedded in the product. The default permission is java.security.AllPermissions.
library.policy	WebSphere Application Server: was_profile_root/config/cells/cell/nodes/node/library.policy	Default permissions (empty) granted to code contained in the shared library (Java library classes) to use in multiple product applications.
app.policy	WebSphere Application Server: was_profile_root/config/cells/cell/nodes/node/app.policy	Default permissions granted to all enterprise applications running on this node, in this cell.
was.policy	Installed EAR: was_profile_root/config/cells/cell/applications/ear_file_name/deployments/application_name/META-INF/was.policy	Permissions assigned to a specific enterprise application, and imbedded within EAR:/META-INF/was.policy.
ra.xml	rar_file_name/META-INF/was.policy.RAR	This file can have a permission specification that is defined in the ra.xml file. The ra.xml file is embedded in the RAR file.

All WebSphere Portal Express code has 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 profile. Enabling Java 2 security will decrease overall system performance to some degree.

• 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 (one), the file grants full access to the code contained in the portlet application. Example 2 (two) shows a was.policy file that implements a more restrictive approach. Example 3 (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 indicate missing Java 2 permissions can be found in the WebSphere Application Server Access Control Exception section of the information center.

 

Parent topic:

Keeping your environment secure

 

Java 2 Security in the WebSphere Application Server information center
http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.express.doc/info/exp/ae/csec_rsecmgr2.html

 

Java 2 Platform Security
http://java.sun.com/j2se/1.3/docs/guide/security/index.html

---