Pega provides the C20 Hotfix for Pega Platform 7.2 through 8.4.2 to add the new role to clients’ systems.

These hotfixes are available at Essential hotfixes.

To complete this process, ensure you have the latest changes, which include important updates.

• For Pega Platform 7.2 through 8.4.2, contact GCS to obtain the appropriate hotfix for your version.

These updates include a PegaRULES:UserRestricted role that improves security by restricting the ability to run activities and reports against certain classes.

Implementing the PegaRULES:UserRestricted role

The PegaRULES:UserRestricted role can be used to augment existing manager and users roles by restricting users with the WorkManager or WorkUser role from having access to developer and system administrator functionality in your Pega applications.

Pega on-premises clients need to request the hotfix, install it, and they must complete the steps below to enable the latest security enhancements which the hotfix introduces to the client's environment.

After Pega Cloud clients receive notice that their environments are running with the C20 hotfix, they must complete the steps below to enable the latest security enhancements which the hotfix introduces to the client's environment.

Purpose of the PegaRULES:UserRestricted role 

Pega provides powerful and precise tools to help you prevent users from accessing areas of the application that they do not need for their business use. One of these tools is the PegaRULES:UserRestricted role. This role restricts access to developer and system administrator functionality, and should be added to all WorkUser and WorkManager access groups, since they should not have that level of access.

For example, a work user should not need to view queue processors, as a system administrator would. 

Adding the UserRestricted role is a simple way for you to restrict WorkUsers and WorkManagers from having access to most of the developer or system administrator functionality. This will increase the security of your application.

Background: Access groups and roles

You can define an access group for operators who have similar responsibilities. When you create an access group, you define permissions and settings that are used for the operators who belong to that access group. Among these permissions are the Access Roles.

For more information, see Access groups.

An access role rule represents a set of capabilities, and usually identifies a job position or responsibility defined for an application.

 

 

 

 

 

When you create an access role, you can configure dependencies from other roles to determine access rights. Role dependencies are relationships between roles that can mirror an organizational hierarchy or more complex relationship between groups of operators, roles, or functional areas.

For example, a manager should have all or almost all the access rights that a user has, plus some access rights that only managers have.

In the Access Group record, add one or more Roles at the bottom of the Definition tab. 

Typically, when the system determines a user's access rights to run a rule in a particular class, it searches the Access of Role to Object ( Rule-Access-Role-Obj ) rules for that class, and looks for all of the access roles listed in the operator’s access group. Access is granted if any of these access roles permit it.

For example (based on access groups shown above):

• The AcmeBank:Manager role has access to the rule CanApproveLoanRequest.
• The AcmeBank:User role has access to the rule CanOpenLoanRequest.
• Therefore, the operators who are in the Access Group Manager have access to both these rules, as that access group has both the Manager and User roles defined.
• Operators in the Access Group User would only be able to run CanOpenLoanRequest.

Access Groups and Roles Names generated in a new application

When you create an application, the New Application wizard creates Access Groups and Roles Names based on the application you selected to build on. This allows for the new application to have a customizable access model that is similar to the model of the built-on application.

Pega Infinity comes with two basic applications on which to build: Classic and Cosmos. When building either of these applications, the four access groups, shown in the table below, are generated and are based on dependent roles. 

For additional information, see Dependent roles.

 

 

Note: *When an access group is managed, another role gets created, which enables the App Studio Page access configuration tool. The name of this role is <AccessGroupName>Managed. 

For example: 

The AcmeBank:Users access group would contain the following roles:

• AcmeBank:User
• AcmeBank:UsersManaged

Dependent roles

In addition to the Roles displayed on the Access Group record, there are dependent roles that are present in the Dependent Role list. 

1. In the navigation of Dev Studio, click Records > Security > Access group.
2. Open the access group you want to edit. In this example, Acmebank: Manager.
3. In the Access Group record, click on the icon next to the Role field to open the Role Name record.

 

 

 

4. In the Role Name record, click Manage dependent roles.

Result: The Manage dependent roles list will display.

 

 

These dependent roles are usually the out-of-the-box roles that cannot be changed. Instead, the application creation process will copy these roles into your application roles, so that you may change those. 

In this example, the role PegaRULES:WorkMgr4 was copied for the AcmeBank:Manager role. 

This is similar to other Pega out-of-the-box rules that you copy into your application and edit.

Like the copied rules, the copied role inherits (is dependent on) the access granted to the original role. So the AcmeBank:Manager role automatically has all the access provided to the PegaRULES:WorkMgr4 role. 

Checking for access

As operators use the application, the system will automatically check whether they have appropriate access to run the rules for various operations. You can control how many access roles are searched and the order in which they are searched. The order in which access roles are searched is determined by the order in which they are listed in the operator’s access group. 

The option Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access lets you specify that the search process stops as soon as the first relevant Access of Role to Object rule is found on one of the roles.

 

 

For example, the Managers Access Group has the following roles:

 

 

If the Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access field 

 

PegaRULES:UserRestricted Role

One of the important steps in securing your application is to verify that users cannot run rules which they are not authorized to run. 

For example, users whose job is to create and handle cases (such as the user at AcmeBank who opens loan applications) should not have access to the system administrator functionality in the application.

Pega provides a powerful and precise set of tools to help you prevent users from accessing areas of the application that they do not need for their business use. Pega provides a role that restricts access to developer and system administrator functionality to simplify setting access for WorkUsers and WorkManagers. The PegaRULES:UserRestricted role should be added to all WorkUsers and WorkManagers Access Groups.

The UserRestricted role can be added in one of two ways:

1. In the Available Roles list, on the Access Groups, see Adding the UserRestricted Role to the Available Roles list for each Access Group.
2. In the Dependent Role list for each role in each Access Group, see Adding the UserRestricted Role to the Dependent Role list for each role.

Prerequisite

Before starting this implementation, you must verify the Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access checkbox is selected.

Adding the UserRestricted Role to the Available Roles list for each Access Group

The system reviews the access of the roles in the order they are listed. Therefore, the PegaRULES:UserRestricted role must be at the top of the list; otherwise, its restrictions would be overridden by whatever role was listed first. 

 

 

1. In the navigation of Dev Studio, click Records > Security > Access group.
2. Open the access group you want to edit. In this example, Acmebank: Manager.
3. Check the field Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access.
4. Click Add role, and choose PegaRULES:UserRestricted from the dropdown. Clicking “add role” will create a new role below the first role. 
5. Copy the first role into this new role, and then change the first role to the PegaRULES:UserRestricted role. The PegaRULES:UserRestricted role must be at the top of the list, move it to the top of the list, if needed. 
6. Save the record.
7. Repeat this process for each WorkUsers and WorkManagers Access Group.

Adding the UserRestricted Role to the Dependent Role list for each role

If you wish to add the UserRestricted role to the Dependent Roles, you must add it to the Dependent list for each role in each Access Group.

1. In the navigation of Dev Studio, click Records > Security > Access group.
2. Open the access group you want to edit. In this example, Acmebank: Manager.
3. Open the Access Group record.
4. Check the Stop access checking once a relevant Access of Role to Object instance explicitly denies or grants access field.

 

 

5. Save the Access Group record.
6. For each role, open the Role Name record, and click Manage dependent roles.
7. In the Add dependent role field, select PegaRULES:UserRestricted. Clicking “add dependent role” will create a new role below the first role. 
8. Copy the first role into this new role, and then change the first role to the PegaRULES:UserRestricted role. The PegaRULES:UserRestricted role must be at the top of the list, move it to the top of the list, if needed. 

 

 

 

9. Click Submit.
10. Repeat this process for each role in each WorkUsers and WorkManagers Access Group.

Errors

After you add the PegaRULES:UserRestricted role to the appropriate Access Groups, if a WorkUsers and WorkManagers attempts to run a restricted rule, the error below can occur.

This error occurred when a user tried to run a restricted activity from a permitted flow:

 

 

This error will also appear in both the PegaRULES log and the Security Alert log.

PegaRULES log

2020-07-28 13:59:34,036 [http-nio-8080-exec-2] [CaseWorker] [                    ] [  AcmeBank:01.01.01] (      internal.mgmt.Executable) ERROR localhost| Proprietary information hidden Proprietary information hidden - Execution denied for class: Work-RuleCheckIn (activity: Nada)

SecurityAlert log

{"actionName":"ACCESS_EXECUTE","appName":"AcmeBank","className":"Work-RuleCheckIn","eventCategory":"Data access event","eventType":"Obj-Open with role based access policy defined","id":"f2a4a933-d9bb-4358-a3bb-30c6044af319","ipAddress":" Proprietary information hidden","nodeID":"prpc-platform-86-web","operatorID":" Proprietary information hidden","outcome":"Failure","requestorIdentity":"20200728T160217","tenantID":"shared","timeStamp":"Tue 2020 Jul 28, 17:59:34:036"}

Resolving the Error

When this error occurs, the application administrator needs to determine if the user should have access to the rule in the error. If the application administrator determines that the user should have access to this rule.

• The application administrator should wrap the PegaRULES:UserRestricted role with an application specific restricted role. You do this by creating a new access role and making PegaRULES:UserRestricted a dependent role.
• Then create an Access of Rule to Object rule for the class of that rule and assign that Access to the new role. This allows the specified user(s) to run the rule.

In the error above, the user does not have access to run the activity Nada in the class Work-RuleCheckIn. Therefore, the administrator must create an Access of Role to Object rule that allows that user role to access this class:

 

 

Testing

Now that you have made these changes, you should test your application before deploying it again. To begin, you should test the users with the changed access groups.