8.1 Authentication, Operator Records & Access Groups

8.1 Authentication, Operator Records & Access Groups

Enterprise security in Pega Platform is founded upon two distinct architectural pillars: Authentication and Authorization. While authentication establishes and verifies the identity of an actor requesting access to the system, authorization dictates precisely what resources, applications, portals, workflows, and case data that authenticated identity is permitted to interact with.

For the Certified Pega System Architect (CSA), mastering the configuration and interplay of Operator ID records (Data-Admin-Operator-ID), Access Groups (Data-Admin-Operator-AccessGroup), and the Enterprise Organization Hierarchy is essential for building compliant, secure, and easily maintainable enterprise solutions.

---

1. Security Architecture Overview: Authentication vs. Authorization

Understanding the clean architectural boundary between authentication and authorization prevents critical security flaws and misconfigurations:

When an external user or API client connects to Pega Platform, the engine first invokes the configured Authentication Service. Once the user's identity is cryptographically or credential-verified, the engine constructs an in-memory Requestor session represented on the clipboard by the system page pxRequestor. Pega then queries the operator's record to load their assigned Access Group, which determines their authorization perimeter.

---

2. Operator ID Records (Data-Admin-Operator-ID)

An Operator ID record (Data-Admin-Operator-ID) represents an individual human user, automated background agent, or external system integration account authorized to access Pega Platform.

Key Configuration Tabs and Parameters

A. Profile Tab (Identity & Credentials)

• Operator ID (pyUserIdentifier): The unique primary key identifier for the user (typically corporate email address or employee network username, e.g., sara.connor@uplusbank.com).
• Full Name & Contact Details: Contact properties (pyFirstName, pyLastName, pyEmailAddress, pyTelephoneNumber) used by automated correspondence and notifications.
• Password & Security: Manages the user's local salted and hashed password if not utilizing Single Sign-On. Flags include Disable operator (preventing any login) and Force password change on next login.
• External Authentication: A checkbox indicating that credentials are authenticated by an external Identity Provider (LDAP/Active Directory, SAML 2.0, or OpenID Connect). When checked, local password fields are disabled.

B. Organization Tab (Organizational Placement)

Every operator must be anchored within the enterprise structure:

• Organization (pyOrganization): The top-level enterprise identifier (e.g., UPlus).
• Division (pyOrgDivision): The major operating subsidiary or line of business (e.g., RetailBanking).
• Unit (pyOrgUnit): The specific branch, department, or cost center (e.g., UnderwritingEast).
• Reporting Manager (pyReportTo): References the Operator ID of the user's direct supervisor. Essential for organizational routing (e.g., cascading managerial approvals).

C. Work Tab (Operational Routing & Skills)

The Work tab dictates how transactional work assignments are routed to and pulled by the operator:

• Primary Work Group (pyWorkGroup): Identifies the operational team the user belongs to (e.g., AutoLoanUnderwriters@RetailBanking).
• Authorized Work Queues: A list of shared work queues (Workbaskets) from which the operator is permitted to process assignments.
• Skills Inventory (pySkills): A Page List defining specific competencies (Rule-Admin-Skill) possessed by the operator along with a proficiency rating score ranging from 1 to 100: $\text{Proficiency Rating} \in [1, 100]$ Example: UnderwritingAuthority = 85, SpanishLanguage = 90. The Get Next Work (GNW) algorithm inspects these ratings against the minimum skill requirements defined on assignments to prevent under-qualified operators from receiving complex cases.

D. Preferences & Localization Tab

• Default Locale: Defines date formats, currency symbols, and numeric conventions (e.g., en_US vs. de_DE).
• Time Zone: The user's operational time zone (e.g., America/New_York or Europe/London). This setting is critical for Service Level Agreements (SLAs), ensuring goal, deadline, and passed-deadline escalation timers calculate accurately relative to local working hours and business calendars.

---

3. Access Groups (Data-Admin-Operator-AccessGroup)

An Access Group is the central authorization junction box in Pega. Individual operators are never granted access roles or application permissions directly. Instead, operators belong to one or more Access Groups, and the Access Group encapsulates their operational privileges.

+-----------------------------------------------------------------------+
|                 DATA-ADMIN-OPERATOR-ACCESSGROUP                       |
+-----------------------------------------------------------------------+
|  1. Application: Name & Version (Ruleset Stack Generation)            |
|  2. Default Portal: Primary UI workspace rendered at login           |
|  3. Available Portals: Switchable secondary UI workspaces             |
|  4. Access Roles: Array of security roles (Rule-Access-Role-Name)     |
|  5. Authorized Work Pools: Class groups permitted for case creation   |
|  6. Production Rulesets: Unlocked rulesets for production delegation   |
+-----------------------------------------------------------------------+

Core Components of an Access Group

1. Application Name and Version

Specifies the exact application rule (Rule-Application) and version number that the user executes (e.g., MortgageLoan:01.02.01). When an operator logs in, the engine inspects this field to assemble the Ruleset Stack for rule resolution. If an application version increments, updating the Access Group seamlessly directs users to the new release without altering individual operator records.

2. Default Portal and Available Portals

• Default Portal: Identifies the primary user interface loaded into the browser immediately upon successful authentication. Common portals include:
  • UserPortal: Tailored for case workers processing assignments and reviewing operational queues.
  • ManagerPortal: Equipped with team dashboards, SLA monitoring widgets, and approval queues.
  • Developer: Provides access to authoring studios (App Studio, Dev Studio, Admin Studio, Prediction Studio).
• Available Portals: A list of alternative portals the user can switch between dynamically from their user menu without requiring a separate login.

3. Access Roles Array (Rule-Access-Role-Name)

An array of one or more security roles granted to any user running under this Access Group (e.g., MortgageApp:Underwriter, PegaRULES:User4). These roles reference Access of Role to Object (ARO) rules to control CRUD permissions and privileges across classes.

4. Authorized Work Pools (Class Groups)

Specifies which Class Groups (Work Pools) the user is permitted to access. This controls which case types appear in the + Create menu in user portals and determines whether the operator can open and search cases residing in those class groups.

5. Production Rulesets

A designated list of unlocked ruleset versions available in production environments for business delegation. This allows authorized business managers to modify specific business rules—such as Decision Tables, Decision Trees, or SLAs—directly in production without requiring an IT deployment or formal CI/CD pipeline release.

Key Architecture Rule: An operator can be associated with multiple Access Groups, but only one Access Group is active at any single moment during a requestor session. Switching applications or roles requires switching the active Access Group via the operator menu.

---

4. Organization Hierarchy & Operational Routing

Pega models enterprise organizational architecture through a three-level structural hierarchy:

        ORGANIZATION (Data-Admin-Organization)
          e.g., GlobalFinancialCorp
                     │
                     ▼
          DIVISION (Data-Admin-OrgDivision)
          e.g., ConsumerLendingDiv
                     │
                     ▼
             UNIT (Data-Admin-OrgUnit)
          e.g., AutoUnderwritingEastUnit

Hierarchy Responsibilities

1. Organization (Data-Admin-Organization): The apex of the enterprise structure. Stores corporate-wide business calendars, default currency conventions, and enterprise-wide password policies.
2. Division (Data-Admin-OrgDivision): Represents a major operational line of business or regional legal entity. Divisions often correspond to the Division Layer of the Enterprise Class Structure (ECS), inheriting enterprise rules while scoping line-of-business policies.
3. Unit (Data-Admin-OrgUnit): The lowest operational subdivision, representing a functional team, physical office branch, or accounting cost center.

Interaction with Work Groups and Routing

While the Org-Div-Unit hierarchy establishes administrative reporting lines, operational case work often spans multiple departments. Pega resolves this through Work Groups (Data-Admin-WorkGroup):

• A Work Group defines a logical team of workers managed by a designated Work Group Manager (Data-Admin-Operator-ID).
• Work Groups can cross Division and Unit boundaries, grouping operators who share common functional responsibilities.
• Each Work Group has a Default Work Queue (Data-Admin-WorkBasket), ensuring work can be routed to a shared queue rather than trapped in individual worklists.

---

5. Password Policies, Multi-Factor Authentication & Enterprise SSO

Enterprise deployments require rigorous identity governance to protect sensitive financial and personal data.

Enterprise Single Sign-On (SSO) Integrations

In enterprise environments, Pega Platform typically acts as a Service Provider (SP) integrating with an enterprise Identity Provider (IdP) using industry standards:

• SAML 2.0 Web SSO: The user authenticates against the corporate IdP (e.g., Okta, Ping Identity, Microsoft Entra ID). The IdP generates a cryptographically signed SAML assertion containing the user's identity and group memberships. Pega's Data-Admin-AuthService validates the SAML response and automatically maps assertion attributes into the operator record.
• OpenID Connect (OIDC) / OAuth 2.0: Cloud-native JSON Web Token (JWT) exchange used for mobile apps, modern web portals, and microservice REST integrations.
• Just-In-Time (JIT) Provisioning: When an authenticated user logs in via SSO for the first time without an existing Operator ID record, Pega can automatically generate the Data-Admin-Operator-ID record on the fly, populating organizational attributes and assigning a default Access Group derived from IdP claim tokens.

Multi-Factor Authentication (MFA)

Pega Platform provides native multi-factor authentication policies configured in Dev Studio (Configure > System > Security > Authentication):

• Trigger Scenarios: Can be enforced globally at login, or triggered step-up on sensitive case actions (e.g., releasing high-value wire transfers).
• Delivery Channels: Generates time-sensitive One-Time Passcodes (OTP) delivered via encrypted email or SMS.
• Verification Windows: Enforces expiration intervals (typically 5 to 10 minutes) and locks OTP entry after a configurable threshold of failed attempts.

Local Password Security Policies

For non-SSO environments and administrative accounts, Pega provides extensive password hardening controls:

• Complexity Requirements: Enforces minimum length (e.g., 12 characters), mandatory character mixes (uppercase, lowercase, digits, special characters), and bans common dictionary terms.
• Account Lockout Governance: Automatically disables an operator account after a defined number of consecutive failed authentication attempts (defaulting to 3 or 5 attempts). Unlocking can require administrator intervention or an automated cooling-off duration.
• Password History & Expiration: Restricts password reuse (preventing the last $N$ passwords from being selected) and enforces periodic password rotation (e.g., mandatory reset every 90 days).

---

6. Architectural Best Practices & CSA Exam Traps