If you deploy Process Commander on IBM WebSphere Application Server and have enabled application security, but not Java 2 security, the log files (PegaRULES.log, SystemOut.log, SystemErr.log, stderr.log, and stdout.log) display several various Java 2 security errors.

For example:

Access denied (java.io.FilePermission . . .)
Access denied (java.net.SocketPermission . . .)
Access denied (java.lang.RuntimePermission . . .)

Note that while Administrative security is enabled by default, you must explicitly enable application security, followed by Java 2 security.

Follow the suggested approach to create and define the Java 2 security policy for your deployment of Process Commander.

Suggested approach

To resolve the Java 2 security errors, create and define the Process Commander security policy at the application level (prrulesecurity.policy) or at the node level (server.policy). Your Process Commander security policy specifies augmented permissions for Process Commander-generated classes, including permissions for Socket Connect and SSLConfig through the WebSphere Application Server policy (was.policy).

The file locations that are shown in the following procedure are examples. Change them to reflect the file locations of your Process Commander environment.

Understanding application-level security versus node-level security

You need to determine where to specify and apply the Java 2 security policy for your environment:

• Application-level security policy is specified in the prrulesecurity.policy file as a WebSphere Application server profile for all instances of Process Commander.

profile_root\PRPC55SP1\prrulesecurity.policy

Example of default location on Windows:

C:\Program Files\IBM\WebSphere\AppServer\profiles\PRPC55SP1\prrulesecurity.policy

Set Java 2 security in the prrulesecurity.policy file if you have distributed Process Commander applications on different nodes within your environment. Defining the Process Commander security policy as a WebSphere Application Server profile ensures that security settings for your SmartBPM environment are contained for your Process Commander applications and do not interfere with other security settings that are controlled by the application server.

• Node-level security policy is specified in the server.policy file for the dedicated Process Commander node.

app_server_root\properties\server.policy

Example of default location on Windows:

C:\Program Files\IBM\WebSphere\AppServer\properties\server.policy

Set Java 2 security in the server.policy file if you have a dedicated node for Process Commander. The settings apply to all applications on the Process Commander node.

Prerequisites

Before you begin, complete these prerequisites:

• If you are using Process Commander Version 5.4 SP2, download and apply the following hotfixes:
  • HFix-1197
  • HFix-1346
• Determine where you need to set Java 2 security for your environment:
  • For application-level scope, set Java 2 security in the prrulesecurity.policy file. Complete all steps of the following procedure.
  • For node-level scope, set Java 2 security in the server.policy file. Begin the following procedure at Step 2.

Procedure

1. If you are setting Java 2 security policy at the application level by using the prrulesecurity.policy file, follow these steps; otherwise go to Step 2:
   1. From the WebSphere Application Server administrative console or the WebSphere Integrated Solutions administrative console, add the following Java properties to the JVM default configuration for the application server:

      If the Java security manager is enabled, PRClassLoader uses ConfigFinder to locate a prrulesecurity.policy file using standard conventions for finding the prconfig.xml file.

      -Dpegarules.rulesecurity.policy=D:\IBM\WebSphere\AppServer\profiles\PRPC55SP1\ prrulesecurity.policy

      -Daxis.ClientConfigFile=D:\IBM\WebSphere\AppServer\profiles\PRPC55SP1\prclient-config.wsdd

      // This is for the SOAP connector in the Axis message processing node. This file is located in APP-INF\lib\ praxis1.2.1.jar

   2. In the location that you specified in Step 1a, create the prrulesecurity.policy file.
2. Open the appropriate security policy file, either prrulesecurity.policy or server.policy, for editing and specify permissions to allow access to the Web Service Deployment Descriptor file (prclient-config.wsdd), the temp directory, the APP-INF\lib directory, Socket Permission class, and the Property Permission class.

Your prrulesecurity.policy or server.policy file should look similar to this example:

grant codeBase "<<ALL RULES>>" {

grant codebase "file:/opt/app/PEGA/prpctemp/-" {

permission java.net.SocketPermission "localhost:1024-", "listen,resolve";

permission java.net.SocketPermission "*", "connect,resolve";

permission java.util.PropertyPermission "*", "read,write";

permission java.io.FilePermission "D:/Server15.5Temp/", "read,write,delete,execute";

permission java.io.FilePermission "D:/Server15.5Temp${/}-", "read,write,delete,execute";

permission java.io.FilePermission "D:/IBM/WebSphere/AppServer/profiles/PRPC55SP1/installedApps/WTWAKXP1Cell01/prpc_ws61.ear/APP-INF/lib/pega${/}-", "read,write,delete,execute";

permission java.io.FilePermission "D:/IBM/WebSphere/AppServer/profiles/PRPC55SP1/installedApps/WTWAKXP1Cell01/prpc_ws61.ear/APP-INF/lib/pega", "read,write,delete,execute";

permission java.io.FilePermission "D:/IBM/WebSphere/AppServer/profiles/PRPC55SP1/prclient-config.wsdd", "read,write,delete";

//For LDAP connection to work, add the following permissions.

permission com.ibm.websphere.security.WebSphereRuntimePermission "getSSLConfig"; permission java.lang.RuntimePermission "modifyThread";

permission java.lang.RuntimePermission "modifyThreadGroup"; };

3. Restart the server and test the system.