Authorization models

Pega Platform applications typically bring many personas (user roles) together to complete work. Roles include Customers, Call Center Workers, Managers, and Administrators. Most users fulfill one of the roles that apply to a given application. Use RBAC to define the actions that one role has authorization to perform on a class-by-class basis, including:

• Class-wide actions, such as running activities or reports.
• Record-level actions, such as opening, modifying (create and update), and deleting.
• Rule-specific actions that are governed by privileges.

Review of role-based access control (RBAC) rule types

Every application has distinct roles that form the basis for authorization. You configure RBAC by using the following rule types: 

• Access group: The collection of access roles that, when aggregated together, form the role-based access control portfolio for a single persona (role).
• Access role: A collection of Access of Role to Object and Access Deny rules that define all role-based access control settings. The settings govern what access the system grants (and denies) to users who receive the access role.
• Access of Role to Object (ARO): Association of an access role to the operations that holders of that access role are granted or denied to perform on an object (such as a class instance).
• Privilege: Rule that can be attached to certain rule types (or parts of them) to authorize who can run(part of) that rule. For example:
  • Only holders of an ApprovePR privilege can perform the Approve Purchase Request flow action.
  • Only holders of a ShowPR privilege can see a Show Purchase Requests menu item configured in a Navigation rule.
• Class: The type of data that is subject to authorization.
• Access When rule: Rule that defines conditional access control (such as a When rule), which typically evaluates one or more properties on the class that is subject to authorization. The intent is that the access control outcome from the Access When rule varies between different instances of the same class. For example:
  • Is the Purchase Request case currently in the Approval stage?
  • Is the salary of an employee greater than USD50,000?
• Access Deny rule: Association of an access role to the operations that the system restricts holders of that access role from performing on an object

The following diagram summarizes the relationships of security rules for RBAC. The Role Name and Rule-Access-role-Obj (RARO) rules are central to RBAC. There is an M:M relationship between Access Group and Role and an M:M relationship between RARO and Privilege. Access Deny rules require Access When rules but are optional for RARO and Privilege rules.

Recent RBAC features

Beginning with Pega Platform version 7.3, the following features became available to enhance RBAC controls further.

• Dependent roles: Allows access roles that you can configure and resolve at run time based on a dependency hierarchy of access roles.
• Privilege inheritance: Privileges that the system grants to a class for an access role (by its ARO) to include the privileges that are specified on AROs of its superclasses in the same access role.
• Short-circuited access checking: Access roles that yield an explicit grant or deny outcome can return this outcome immediately without checking subsequent access roles on the Access Group when (particularly in the case of an explicit grant) the eventual access control decision is to grant access.
• App Studio-managed authorization: App Studio provides a basic authorization configuration feature that supplements the RBAC foundation that Dev Studio provides. You select the Enable page access configuration checkbox in the access group in App Studio to allow citizen developers to manage the access roles.

The importance of privileges

Privileges provide better security because they can be used to control access to individual rules or parts of individual rules.

Privileges are a critical component of your authorization strategy because they allow the execution of specific rules to be explicitly authorized “just in time.” Privileges complement the security and access control features of access roles and ruleset lists by restricting access to specific rules rather than entire classes or RuleSet versions. Use privileges to differentiate the capabilities of different groups of users within your application. Privileges can prevent the unintended execution of a rule with unforeseen use of the application.

Run-time role resolution and privilege inheritance 

When you define ARO rules on a class basis, Pega Platform navigates the class hierarchy and determines the most specific ARO relative to the class of the object for that role. The system ignores any less specific AROs in the class hierarchy for that role. The system allows users to perform the operation if the most specific ARO allows the operation. If users have multiple roles, the system determines the most specific ARO rules for each role. Pega Platform performs the operation if the operation is allowed in any of the most specific AROs.

Privileges can provide more granular security because individual rules define them. For example, to run a flow action secured by a privilege, the user requires the privilege. The system grants the privilege through the most specific AROs for the class of the object. However, there is an option for the role to inherit privileges in AROs that are defined in the class hierarchy. With this option, users receive all the privileges that are granted by the AROs, which are defined for the classes in the class hierarchy of the object.

In the following example, the role has the option for inheriting privileges selected. If the user works on an Expense Report case, the access rights are defined in the TGB-HRApps-Work-ExpenseReport row. The role inherits additional privileges from the class hierarchy (TGB-HRApps-Work and Work-).

ABAC complements RBAC through Access Control Policies to control access to specific attributes of a record (so long as RBAC grants access to the record), regardless of the location of those attributes in the application (for example, on a screen or in a report). You can also use ABAC to define record-level access control (additional to RBAC), where the role that the user fulfills for the application does not determine the conditions for accessing those records. The following table shows the authorization types with the associated rules and the access controls.

Use of ABAC in an application is optional; ABAC compares user information to case data on a row-by-row or column-by-column basis. You configure ABAC by using Access Control Policy rules that specify the type of access. Access Control Policy Condition rules define policy conditions that compare user properties or other information on the clipboard to properties in the restricted class.

You define access control policies for classes inheriting from Assign-, Data-, and Work- and use the full inheritance functionality of Pega Platform. Access control policy conditions are joined with an AND operation when multiple same-type access control policies exist in the inheritance path with different names. The system allows access only when all defined access control policy conditions are satisfied.

In the following example, if a user of an HR application wants to update a Purchase case, the conditions for the access control policies defined in the class hierarchy are joined with an AND condition. The user receives access to update the Purchase case only if WorkUpdate AND HRUpdate AND HRPurchaseUpdate evaluate to true.

If you disabled ABAC in the past, you can enable ABAC by updating a dynamic system setting. For more information, see Enabling attribute-based access control.

Another access control feature in Pega Platform is client-based access control (CBAC). CBAC focuses on tracking and processing requests to view, update, or remove personal customer data that Pega Platform holds across your applications, such the that that EU GDPR (and similar) regulations require. It does not influence the authorization considerations for lead system architects when designing a Pega application and is not discussed further in this module.

For more information about CBAC, see Defining client-based access control rules.

Check your knowledge with the following interaction: