Authorization models

Pega applications typically bring many personas (user roles) together to get work done. Roles include Customers, Call Center Workers, Managers, and Administrators. Most users fulfill one of the role's applicable for a given Application. RBAC defines the actions that one role is authorized to perform on a class-by-class basis, including:

• Class-wide actions: Execute Activities, Run Reports
• Record-level actions: Open, Modify (Create and Update), Delete
• Rule-specific actions as 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 defining all role-based access control settings that govern what access is granted (and denied) to those users who are allocated 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 execute (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 within a Navigation rule.
• Class: The type of data that is subject to authorization.
• Access When rule: Rule defining conditional access control (like a regular When rule) which typically evaluates one or more properties on the Class subject to authorization. The intent is that the access control outcome yielded 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 Employee’s salary greater than USD50,000?
• Access Deny rule: Association of an access role to the operations that holders of that access role are explicitly denied to perform on an object.

Recent RBAC features

The following features have emerged in recent releases of the Pega Platform that further influence role-based access control. Examples of each are discussed in later modules.

• Dependent roles: Allows access roles to be configured and resolve at runtime based on a dependency hierarchy of access roles
• Privilege inheritance: allows Privileges granted to a Class for an access role (by its ARO) to include those Privileges specified on AROs of its superclasses within 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 capability that supplements the RBAC foundation provided by Dev Studio. To allow citizen developers to manage the access roles, please check Enable page access configuration in App Studio setting in the access group.

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 provide an opportunity for the execution of certain rules to be explicitly authorized “just in time.” Privileges complement the security and access control features provided by access roles and RuleSet lists, by restricting access to specific rules rather than to 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 usage of the application.

Runtime role resolution and privilege inheritance

When you define Access of Role to Object (ARO) rules on a class basis, Pega navigates the class hierarchy and determines the most specific ARO relative to the class of the object for that role. Any less specific AROs in the class hierarchy for that role are ignored. The operation being performed is allowed if the most specific ARO allows the operation. If the operator is granted multiple roles, the most specific ARO rules are determined for each role. Pega Platform performs the operation if the operation is allowed in any of the most specific AROs.

As stated, privileges can provide more granular security because they are defined on individual rules. For example, to execute a flow action secured by a privilege, the user must be granted the privilege. The privilege is granted through the most specific AROs for the Class of the object. There is, however, an option on the role for inheriting privileges within AROs defined in the class hierarchy. Selecting this option provides the operator with all the privileges granted by the AROs that 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 row highlighted in bold. Additional privileges are inherited from the class hierarchy (TGB-HRApps-Work and Work-).

ABAC complements RBAC by enabling Access Control Policies to control access to specific attributes of a record (so long as RBAC has granted access to the record), regardless of where those attributes are used in the application (on a screen, in a report). You can also use ABAC to define record-level access control (additional to RBAC) where the role that the operator fulfills for the application does not determine the conditions for accessing those records.

ABAC is optional and used in conjunction with RBAC. 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 and Access Control Policy Condition rules defining a set of 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. Access is allowed only when all defined access control policy conditions are satisfied.

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

If you have disabled ABAC in the past, you can enable ABAC by updating the following Dynamic System Settings:
 
Short description: Enable Attribute-Based Security
Owning Ruleset: Pega-RulesEngine
Setting Purpose: EnableAttributeBasedSecurity
Value: true
RS: Pega-ProcessCommander

Another access control capability in Pega is client-based access control (CBAC). This is more focused on tracking and processing requests to view, update or remove personal Customer data held across your Pega applications, such as that required by EU GDPR (and similar) regulations. 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.