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.

Configuring access for troubleshooting Pega Cloud production environments

Updated on September 25, 2019

Customers with stringent compliance requirements for their Pega Cloud environments often need to restrict write access to their test and production systems. However, developers might still need access to the Pega 7 Platform Designer Studio to troubleshoot and debug problems. This article describes how you can create an access group for users with administrator roles and read-only access so that they can view rule forms for troubleshooting purposes, but still adhere to compliance requirements because these users cannot edit rules or data.

Prerequisites

  • Security-related rules that you create by using this procedure cannot be combined with rules that are used in production or undergoing testing.
  • You must have permissions to create security rules to create access groups for this purpose.
  • You should have some familiarity with the following record types:
    • Operator IDs
    • Access groups
    • Access roles
    • Access of role to object records

To create an access group with read-only permissions, complete the following tasks:

Creating a ruleset and ruleset version

Create a new ruleset and ruleset version. Leave the option Update my current application to include the new version unselected.

Leaving this option unselected helps prevent the rules that you create in this procedure from being moved unintentionally into a production environment along with other application ruleset versions. It also allows these rules to be moved from one testing environment to another without affecting existing applications.

Creating an Operator ID

As a best practice, create a new Operator ID instead of creating one from an existing Operator ID, because you can ensure that only the access privileges that you specify are provided to this user. In the future, you might want to create named users that are copies of this user. This way, you can see who is logged in to the Pega 7 Platform to perform system maintenance.

  1. Create a new Operator ID.
  2. In the Operator ID rule form, click [Edit] to update the Operator ID ruleset with the ruleset that you just created. This action includes the new Operator ID in the package when the rules are exported.
  3. On the Profile tab, under Contact Information, enter a full name for the Operator ID as described in the help topic.
  4. Optional: On the Security tab, click Update Password to change the password. The default password is rules.
  5. On the Security tab, leave the Allow rule check out check box unselected.
  6. On the Work tab, under Organizational Unit, click Update.
  7. In the Update Organizational Unit dialog box, click pega.com > Administration > Installation, and click Update. This action adds the new Operator ID to the access group PRPC:WorkUsers, which gives the user access to basic case management features. If you choose a different organization or division, review them to ensure that they do not grant access to Administrator access groups.
  8. On the Profile tab, enter a name for the new access group. A recommended name format is YourApplicationName:LimitedAccess. Make sure that there is a colon in the access group name after the application name.
  9. Select and open the new Access Group.

Configuring the access group

To configure the access group:

  1. In the Access Group form, add a short description.
  2. Click Create and open.
  3. Click [Edit] to update the Associated RuleSet. Select the new ruleset that you created for this purpose. This action includes this access group in the package when the rules are exported.
  4. On the Definition tab, do the following steps:
    1. Under Application, in the Name field, press the Down Arrow key and select your application from the list. Do the same in the Version field to select the application version. This action gives the new Operator ID access to the rules and data in your application. It does not describe the kind of access that they have.
    2. Under Available portals, click in the Name field, press the Down Arrow key, and select Developer from the list. This action gives the Operator ID the ability to log in to Designer Studio, but it does not define the kind of access that the operator has.
    3. Click in the Available roles field, press the Down Arrow key, and select a role from the list, for example, <YourApplicationName>:User. This temporary value is required to save the rule.
  5. On the Advanced tab, under Work Pools, click in the Name field and press the Down Arrow key to select a work pool from your application to add to the access group. The Operator ID uses this selection as the default work pool in the Application Explorer.
  6. Click Save.
  7. Switch tabs to the Operator ID rule form, and click Save.

Creating an access role

Create an access role that is similar to an Administrator role, but it does not have the same privileges and access classes.

While this task is being completed, make sure that no one attempts to export the application.
  1. In the Designer Studio header, click the name of your application and click Open Application.
  2. On the Definition tab, under Application rulesets, click Add ruleset.
  3. Click in the new ruleset field, press the Down Arrow key, and select the ruleset that you created from the list, for example: LimitedRole:01-01.
  4. Click Save.
  5. Create the access role. Configure the access role as follows:
    • Clone From – Press the Down Arrow key and select the Administrator role from your application, for example: <YourAppName>:Administrator.
    • Create Workbasket – Clear this option.
    • RuleSet – Press the Down Arrow key and select LimitedRole.
    • RuleSet Version – Press the Down Arrow key and select 01-01-01.
  6. Click Submit.
  7. On the Groups and Roles landing page, click Submit.
  8. In the list of roles, click the newly created role to open the Access Role Name rule form.
  9. Return to your Application rule form and remove the newly created ruleset from your application.
  10. Click Save and close the application.
  11. Return to the Access Role Name rule form. In the Access Class column, click @baseclass.
  12. In the Add/Edit role dialog box, do the following actions in the @baseclass row:
    1. Change the Privilege values for Write instances, Write rules, Delete instances, and Delete rules to 0.
    2. Under Privileges, delete the following rows:
      • zipMoveExport
      • zipMoveImport
      • zipMoveSkim
      • pySchemaBuilderAllAllowed
      • SchemaImport
      • SchemaPropertyOptimization
      • SchemaTableCreation
      • ViewAndOptimizeSchema
      • pxHotfixManagement
      • pxExecuteActivityFromClipboard ​
  13. Click Submit.
  14. In the AccessClass column, click Rule-.
  15. In the Add/Edit role dialog box, do the following steps in the Rule- row:
    1. Change the Privilege values for Write instances, Write rules, Delete instances, and Delete rules to 0.
    2. Under Privileges, delete the following rows to remove these privileges from the access class:
    • UpdatePrivateRulesets
    • zipMoveExport
    • zipMoveImport
    • zipMoveSkim
    • pxAllowPrivateCheckout
    • pxCanDelegateRules
  16. Click Submit.​
  17. On the Access Role rule form, delete the following classes to remove them from the access role:
​If your users might be troubleshooting JMS connect rules or MQ connect rules, do not delete these classes. Instead, change Write instances, Write rules, Delete instances, and Delete rules to 0 as described in steps 12 and 15 for @baseclass and Rule-.
  • Data-Admin-Connect-
  • Data-Admin-Operator-AccessGroup
  • Data-Admin-Operator-ID
  • Data-Admin-Requestor
  • Data-Admin-System-AuthPolicies
  • Data-Admin-System-Settings
  • Data-Mobile-
  • Data-SecurityVAUtility
  • PegaAccel-Task-GenerateApp​
  • PegaAccel-Task-ProposeApp​
  • Pega-Landing​
  • Rule-Access-Role-Obj
  • Rule-Access-When
  • Rule-Application
  • Rule-Connect-JMS
  • Rule-Connect-MQ

Adding the access role to the access group

After you create the access role for your new Operator ID, you must add it to the access group that you created.

  1. Open the Limited Operator ID.
  2. Select and open the new access group that you created.
  3. On the Edit Access Group:LimitedAccess screen, add the new access role that you created, for example,<YourAppName>:LimitedAdministrator.
  4. Click Save.
  5. Lock the ruleset version of the access role that you created earlier. This action limits the possibility of someone saving rules to this ruleset in error.
If the rulesets created for this scenario are moved into a production environment, lock them securely with passwords that are similar in complexity to the passwords that are used to secure application rulesets that are deployed into production.

Tags

Pega Cloud 2.1 Pega Cloud Pega Platform 7.1.1 - 7.4 Security

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.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us