Pega Security Model

Pega's security model is built on two pillars: Authentication (who are you?) and Authorization (what can you do?).

Authentication — confirming identity via login credentials. The Operator ID record contains the information needed to authenticate a user.

Authorization — determining what the user can access. This is controlled by a chain of security rules:

Operator ID
  └── Access Group (active persona)
       ├── Application + Version
       ├── Available Portals
       └── Access Roles (1 or more)
            ├── ARO (Access of Role to Object)
            │     ├── Class-level permissions (0-5 scale)
            │     ├── Privileges (granted)
            │     └── Access When conditions
            └── Access Deny
                  ├── Class-level denials
                  └── Access When conditions (required)

The flow when a user logs in:
1. User enters credentials → Pega checks the Operator ID record
2. Operator ID identifies the default Access Group
3. Access Group identifies the Application, Portal, and Access Roles
4. Access Roles contain ARO rules that define what actions are allowed
5. When the user tries to do something, Pega checks ARO permissions + Privileges

Two authorization models in Pega:
■RBAC (Role-Based Access Control) — controls access based on user roles. Uses Access Groups, Access Roles, AROs, Privileges, and Access Deny rules.
■ABAC (Attribute-Based Access Control) — controls access based on data attributes. Uses Access Control Policies and Policy Conditions. Complements RBAC.

Key principle: ABAC can further restrict what RBAC allows, but ABAC alone cannot grant access. If RBAC denies access to a record, ABAC cannot override that denial.