8.2 Role-Based Access Control: Access Roles, ARO & Privileges

8.2 Role-Based Access Control: Access Roles, ARO & Privileges

In Pega Platform, Role-Based Access Control (RBAC) is the foundational security model governing what actions a user can perform on specific classes and rule types. While an Access Group connects an operator to an application and portal, RBAC determines whether that user can open a case, modify properties, delete records, run reports, or execute sensitive transactional stages.

Understanding the mechanics of Access Roles (Rule-Access-Role-Name), Access of Role to Object (ARO) rules (Rule-Access-Role-Obj), and granular Privileges (Rule-Access-Privilege-Name), along with Pega's multi-role resolution algorithm, is a heavily tested topic on the Certified Pega System Architect exam.

---

1. Role-Based Access Control (RBAC) Architecture

Pega's RBAC framework enforces the security principle of least privilege, ensuring users possess only the permissions required to fulfill their business responsibilities. The architecture is structured around three foundational rule types:

+-------------------------------------------------------------------------+
|                         PEGA RBAC CORE ENTITIES                         |
+-------------------------------------------------------------------------+
| [1] ACCESS ROLE NAME (Rule-Access-Role-Name)                            |
|     Reusable security persona label (e.g., LoanApp:Underwriter)         |
|                                                                         |
| [2] ACCESS OF ROLE TO OBJECT (ARO) (Rule-Access-Role-Obj)               |
|     Security matrix mapping an Access Role to a specific Class         |
|     Defines CRUD permissions (0-5) and conditional When rules           |
|                                                                         |
| [3] PRIVILEGE (Rule-Access-Privilege-Name)                              |
|     Atomic security token granting right to execute a discrete action   |
|     Checked on Flow Actions, Stages, Activities, and Flows              |
+-------------------------------------------------------------------------+

The RBAC Authorization Chain

1. An Operator logs in and is initialized with an active Access Group.
2. The Access Group contains an array of Access Roles.
3. For each Access Role, the system evaluates matching Access of Role to Object (ARO) rules for the target case or data class.
4. The ARO defines class-level operation permissions (0 to 5) and grants specific Privileges.
5. When a user attempts to execute a case action or open a screen, Pega verifies that the user's role hierarchy grants the necessary ARO level and required Privileges.

---

2. Access Roles (Rule-Access-Role-Name)

An Access Role is a named authorization persona that defines a specific job function or security classification within an application.

Characteristics and Naming Conventions

• An Access Role name rule (Rule-Access-Role-Name) contains no logic or settings of its own; it serves as a reusable identifier or grouping key.
• Pega best practice dictates naming roles using the pattern ApplicationName:RoleName:
  • LoanApp:User: Standard case workers who create and process general cases.
  • LoanApp:Underwriter: Subject matter experts who evaluate risk and approve terms.
  • LoanApp:Manager: Supervisors with reporting, transfer, and reassignment authority.
  • LoanApp:Administrator: IT administrators with system configuration rights.
  • PegaRULES:SysAdm4: The out-of-the-box system administrator role granting full platform development and administrative access.

An Access Group can reference multiple Access Roles simultaneously. For example, a senior supervisor might be assigned both LoanApp:Underwriter and LoanApp:Manager within their LoanApp:Supervisors Access Group.

---

3. Access of Role to Object (ARO / Rule-Access-Role-Obj)

The Access of Role to Object (ARO) rule is the heart of Pega RBAC. An ARO links an Access Role to a specific Class (Applies-To) and explicitly defines what operations users holding that role may perform on instances of that class.

The Permission Operations

Each ARO configuration matrix specifies permissions for seven standard operations:

The 0 to 5 Permission Scale

Permissions for each operation are defined using an integer scale from 0 to 5:

• 0 (No Access): Explicitly denies the operation. Users with this role cannot perform the action.
• 1 to 4 (Conditional / Tiered): Used in specialized legacy designs or combined with custom security thresholds.
• 5 (Full Access): Unconditionally authorizes the operation.

Dynamic Access with When Rules

Rather than entering a static integer between 0 and 5, architects can enter the name of a When rule (Rule-Obj-When) into any operation field:

• If the When rule evaluates to true at runtime, Pega treats the permission level as 5 (granted).
• If the When rule evaluates to false, Pega treats the permission level as 0 (denied).

Common Real-World Example: Setting the Modify Cases permission on UPlus-Loans-Work-Mortgage to a When rule named IsCaseModifiable:

IsCaseModifiable When Condition:
.pyStatusWork != "Resolved-Completed" AND .pyStatusWork != "Resolved-Rejected"

This ensures underwriters can modify cases while they are actively progressing, but prevents any edits once a case reaches a resolved status.

---

4. Privileges (Rule-Access-Privilege-Name)

While ARO CRUD settings control broad class-level capabilities, enterprise workflows require fine-grained authorization over specific transactional actions. This is accomplished using Privileges (Rule-Access-Privilege-Name).

A Privilege is an atomic, discrete security token that authorizes an operator to execute a specific sensitive action.

       ARO (Privileges Tab)                FLOW ACTION (Security Tab)
  ┌─────────────────────────────┐        ┌─────────────────────────────┐
  │ Role: LoanApp:Underwriter   │        │ Flow Action: OverrideRate   │
  │ Class: UPlus-Loans-Work-    │        │ Required Privileges:        │
  │ Grants: CanOverrideRate     │ ─────> │  - CanOverrideRate          │
  │ (Unconditional or When rule)│        │ (Action blocked if missing) │
  └─────────────────────────────┘        └─────────────────────────────┘

Where Privileges Are Enforced

Architects attach required privileges to sensitive platform components:

1. Flow Actions (Rule-Obj-FlowAction): Configured on the Action tab under Security. If a user does not possess the specified privilege, the flow action will not appear in the UI actions dropdown, and the engine rejects any attempt to submit it.
2. Case Stages (Rule-Obj-CaseType): Restricts entry or execution of specific stages (e.g., an Executive Settlement stage) to users holding a designated privilege.
3. Activities (Rule-Obj-Activity): Configured on the Security tab under Privileges. If an activity is invoked without the caller holding the privilege, the engine halts execution with a security violation.
4. Flows and Sub-processes: Restricts manual flow launching to authorized personas.

Granting Privileges via the ARO Rule

Privileges are granted within the Privileges tab of the ARO rule form:

• The architect adds the privilege name (e.g., CanOverrideCreditLimit or ReopenResolvedCase).
• The grant can be unconditional (level 5) or governed by a When rule (e.g., grant CanOverrideCreditLimit only When .ApplicantCreditScore > 750).

---

5. Security Resolution Algorithm & Multi-Role Inheritance

Enterprise operators frequently hold multiple Access Roles within their Access Group. Furthermore, classes inherit rules through Pattern and Directed inheritance. How does Pega determine whether an action is permitted?

A. The Multi-Role Union Rule: "Highest Permission Wins"

When an operator's Access Group references multiple Access Roles, Pega evaluates all ARO rules applicable to that class across all assigned roles and applies the most permissive result:

$\text{Effective Permission} = \max(\text{Role}_1, \text{Role}_2, \dots, \text{Role}_n)$

• If Role_A grants Write permission 0 and Role_B grants Write permission 5, the operator receives 5 (Allowed).
• Critical Architectural Principle: In Pega RBAC, there is no "veto" or explicit deny role that overrides an allowed role. The highest integer wins.
• If multiple roles specify When rules, Pega evaluates them with logical OR: if any When condition evaluates to true, access is granted.

B. Class Inheritance Resolution for ARO Rules

If no explicit ARO rule exists for the specific case class, the Pega security engine traverses the class hierarchy using Pattern Inheritance and Directed Inheritance:

1. Pega searches for an ARO rule defined directly on the target class (e.g., UPlus-Loans-Work-Mortgage).
2. If not found, the engine follows Pattern inheritance to search parent classes (e.g., UPlus-Loans-Work-, then UPlus-Loans-, then UPlus-).
3. If still not found, the engine evaluates Directed inheritance parents (e.g., Work-Cover-, Work-, and finally @baseclass).
4. First Match Stops the Search: The engine uses the first matching ARO rule encountered along the inheritance path for that role. It does not merge ARO settings across different levels of the class inheritance chain for the same role.
5. If @baseclass is reached without finding an ARO rule for that role, the operation is denied (0) by default.

---

6. Security Anti-Patterns & CSA Exam Traps