Skip to main content

         This documentation site is for previous versions. Visit our new documentation site for current releases.      

This content has been archived and is no longer being updated.

Links may not function; however, this content may be relevant to outdated versions of the product.

How to define Java 2 Security policies for Process Commander (WebSphere)

Updated on October 2, 2015

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 ( . . .)
Access denied ( . . .)
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.


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.


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.


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.
Use of Java 2 Security policies requires configuration of SSL security settings to ensure the proper operation of the Integration features in Pegasystems products.


  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


      // 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 "localhost:1024-", "listen,resolve";

permission "*", "connect,resolve";

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

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

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

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

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

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

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

permission "getSSLConfig"; permission java.lang.RuntimePermission "modifyThread";

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

3. Restart the server and test the system.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best. is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us