Use Java 2 security with WebSphere Portal

 

+
Search Tips   |   Advanced Search

 

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 us 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.

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 was_profile_root/profiles/profile/properties/server.policy Default permissions granted to all product servers.
client.policy was_profile_root/profiles/profile/properties/client.policy Default permissions for all of the product client containers and applets on a node.
spi.policy was_profile_root/profiles/profile/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 was_profile_root/profiles/profile/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 was_profile_root/profiles/profile/config/cells/cell/nodes/node/app.policy Default permissions granted to all enterprise applications running on this node, in this cell.
was.policy was_profile_root/config/cells/cell/applications/EarFile/deployments/appname/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 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 we 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...

    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 the 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.

 

Related information

 

Parent Topic

Keeping the environment secure