Links may not function; however, this content may be relevant to outdated versions of the product.
Configuring access for troubleshooting Pega Cloud production environments
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:
- Create a ruleset and ruleset version
- Create an Operator ID
- Configure the access group
- Create an access role
- Add the access role to the access group
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.
- Create a new Operator ID.
- 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.
- On the Profile tab, under Contact Information, enter a full name for the Operator ID as described in the help topic.
- Optional: On the Security tab, click Update Password to change the password. The default password is rules.
- On the Security tab, leave the Allow rule check out check box unselected.
- On the Work tab, under Organizational Unit, click Update.
- In the pega.com > Administration > Installation, and click . 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. dialog box, click
- 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.
- Select and open the new Access Group.
Configuring the access group
To configure the access group:
- In the Access Group form, add a short description.
- Click .
- 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.
- On the Definition tab, do the following steps:
- 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.
- 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.
- 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.
- 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.
- Click Save.
- 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.
- In the Designer Studio header, click the name of your application and click .
- On the Definition tab, under Application rulesets, click Add ruleset.
- 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.
- Click Save.
- 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.
- Click Submit.
- On the Groups and Roles landing page, click Submit.
- In the list of roles, click the newly created role to open the Access Role Name rule form.
- Return to your Application rule form and remove the newly created ruleset from your application.
- Click and close the application.
- Return to the Access Role Name rule form. In the Access Class column, click @baseclass.
- In the @baseclass row:
- Change the Privilege values for Write instances, Write rules, Delete instances, and Delete rules to 0.
- Under Privileges, delete the following rows:
- zipMoveExport
- zipMoveImport
- zipMoveSkim
- pySchemaBuilderAllAllowed
- SchemaImport
- SchemaPropertyOptimization
- SchemaTableCreation
- ViewAndOptimizeSchema
- pxHotfixManagement
- pxExecuteActivityFromClipboard
dialog box, do the following actions in the - Click .
- In the AccessClass column, click Rule-.
- In the Add/Edit role dialog box, do the following steps in the Rule- row:
- Change the Privilege values for Write instances, Write rules, Delete instances, and Delete rules to 0.
- Under Privileges, delete the following rows to remove these privileges from the access class:
- UpdatePrivateRulesets
- zipMoveExport
- zipMoveImport
- zipMoveSkim
- pxAllowPrivateCheckout
- pxCanDelegateRules
- Click Submit.
- On the Access Role rule form, delete the following classes to remove them from the access role:
- 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.
- Open the Limited Operator ID.
- Select and open the new access group that you created.
- On the Edit Access Group:LimitedAccess screen, add the new access role that you created, for example,<YourAppName>:LimitedAdministrator.
- Click .
- 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.