Role-based access control (RBAC)

Application and data security are major concerns due to the risk of a data breach leading to customer loss and legal or financial penalties. You can satisfy common security requirements by controlling the application features and functions users can access.

Consider a process for employee review that includes an assignment to authorize a raise for an employee. The assignment is routed to a common work queue accessible by all members of the Human Resources (HR) department. Due to privacy concerns, stakeholders want to restrict access to raise proposals to only members of the HR department that are authorized to access compensation information. By granting authorization to specific members of the HR department, you can reduce the chance of unauthorized access to personal identifying information (PII).

Access roles

An access role categorizes users according to their job function. Each access role represents how a set of users interacts with an application to create and process cases. For example, in an application for managing purchase requests, any user can submit a purchase request, but only a manager can approve a purchase request.

Each access group references one or more access roles. By allowing references to multiple roles on an access group, Pega Platform encourages the design of a modular application security model in which you combine granular roles to meet complex security needs.

For each access role, you configure permissions to control actions on instances of a specific class, such as the types of cases that a user can create or modify. If the roles referenced by an access group provide conflicting access control configurations, Pega Platform applies the most permissive setting across all the conflicting roles. In the following example, a manager belongs to an access group that includes both the User and Manager access roles. The Manager access role allows users to approve and submit a time-off request, while the User access role prohibits approval and submission actions. Because the Manager access group references both roles, members of the access group can approve and submit time-off requests.

Check your knowledge with the following interaction.

Access of Role to Object

The foundation of the RBAC model is the Access of Role to Object (ARO) record. You use an ARO record to define the access control settings for instances of a specific class. Each ARO identifies the actions that a role can perform on instances of the specified class. For example, an ARO named PurchaseRequest:Administrators associated with a class that describes purchase request cases may allow users to open cases, but not to run reports.

Each ARO corresponds to a unique combination of access role and class. This allows Pega Platform to apply permissions configured in the ARO to the users in a particular role.

With an ARO, permissions are granted on a 0-5 scale, where 0 denies permission to perform an action. The values 1-5 grant permission on a system with the same or a lower production level, as indicated in the following list.

1. Experimental/Sandbox 
2. Development
3. Test/Quality assurance
4. Pre-Production/Staging
5. Production

For example, entering a permission setting of 5 for the View case history action allows a user to view the case history on a production system or any system with a lower production level setting. Entering a permission setting of 3 would allow a user to view the case history on a development or testing system, but not a staging or production system.

Access Deny

By default, Pega Platform denies access to all instances of a class unless you explicitly grant access to users. In situations where regulations and policies require explicit denial of access to specific capabilities you can configure an Access Deny record.

Access deny records are functionally similar to AROs. As with an ARO, each access deny record corresponds to a unique combination of role and class. With an access deny record, you deny permission for an action using a 0-5 scale, where 0 indicates that the action is allowed. The values 1-5 indicate that the action is denied on a system of the same or a higher production level.

For example, if an access deny record sets the permission for viewing case history on instances of the Purchase Request case type to 5, then the action is denied on a production system.

Privilege

A Privilege record is used to control access to a specific rule. Most rules list any required privileges on the Security tab of the rule form, except for flow rules, which list required privileges on the Process tab. A rule can list multiple privileges. Granting any of the listed privileges to the user allows the user to run the rule.

A privilege record acts as a token. If a rule requires a privilege to run, only users granted the privilege can run the rule. To grant a privilege to a role, add the privilege record to the appropriate ARO.

Privileges are considered during the rule resolution process, but only after a candidate rule has been added to the rules cache. If a user attempts to run a rule without a required privilege, the application returns an error rather than attempting to run a different version of the rule.

Access When

Similar to a when condition, you configure an Access When record to define logic for configuring conditional permissions for actions. Access when records return a result of either true or false. If the record returns false, the access control setting is considered to be zero (0). If the record returns true, the access control setting is considered to be five (5). This ensures that any conditional permissions are not affected by the production level of the system.

To apply conditional logic to an access control setting, enter the name of the access when record in the field that corresponds to the action or privilege on either an access deny or ARO record.

Check your knowledge with the following interaction.