PEGA SECURITY

Pega Security – Part 1: Authentication, Operator, Access Group, Roles & Privileges

Understanding Pega security becomes much easier when you follow the user's journey from login to authorization.

Pega security has several moving parts, and when you first start working with it, terms like Authentication, Operator, Access Group, Application, Role, and Privilege can feel like separate concepts.

The easiest way to understand them is to follow one user through the system.

First Pega identifies who you are.

Then it determines what application and security context you are working in, and finally what you are allowed to do.

Let's use a real-world example

Throughout this series, we'll use a fictional bank called Alpha Bank.

Alpha Bank uses Pega to manage business processes such as customer onboarding, account opening, loan applications, card requests, and customer service.

Pega Security – End-to-End Flow: from user authentication to data and API authorization

Now imagine an employee named John. John is a Loan Manager at Alpha Bank.

When John logs into Pega and opens a loan application, several security concepts work together behind the scenes.

The Pega Security Flow

A simple way to remember the overall flow is:

Authentication → Operator → Access Group → Application → Role → Privilege

Each step answers a different question.

1. Authentication — Who are you?

Authentication is the first step. It verifies the identity of the person trying to access the application.

In an enterprise environment, Pega may use technologies such as SAML, OIDC, or other authentication mechanisms, depending on the architecture.

For example, Alpha Bank uses Single Sign-On (SSO). John enters the Alpha Bank application and is redirected to the organization's identity provider. After successful authentication, the identity provider tells Pega that John has been authenticated.

Easy way to remember:
Authentication answers: "Who are you?"

Authentication establishes identity. It does not by itself determine everything the user is allowed to do inside the application.

2. Operator — Who are you inside Pega?

Once the user has been authenticated, Pega needs to associate that identity with a Pega user.

This is where the Operator ID comes into the picture.

For example, John's Pega Operator ID might be:

John.Smith

The Operator record contains information Pega needs to establish John's application and security context.

Easy way to remember:
Authentication proves who you are.
Operator represents you inside Pega.

3. Access Group — What application and security context are you using?

The Access Group establishes the application and security context in which the user works.

Alpha Bank might have access groups such as:

AlphaBankEmployee

General employee access

AlphaBankLoanManager

Loan management access

AlphaBankAdministrator

Administrative access

So, if John is working as a Loan Manager, his active access group determines the application context and security configuration available to him.

Easy way to remember:
Operator = who you are
Access Group = the application/security context you are working in

4. Application — What Pega application are you using?

The Access Group establishes the application context in which the user works.

In our Alpha Bank example, the application may contain capabilities such as:

• Customer Onboarding
• Account Opening
• Loan Application
• Card Request
• Customer Service

The application represents the broader business and technical context. However, having access to the application does not automatically mean that the user can perform every action within it.

5. Roles — What type of work can you perform?

A Role defines a broader set of permissions associated with a user's responsibilities.

Alpha Bank could have roles such as:

CustomerService LoanOfficer LoanManager Administrator

John, as a Loan Manager, may have permissions associated with reviewing, approving, or rejecting loan applications.

Easy way to remember:
Role = what type of work the user is responsible for.

6. Privileges — Can you perform this specific action?

A Privilege provides more granular control over a specific protected capability or action.

For example, Alpha Bank may protect the Approve Loan action with a privilege called:

ApproveLoan

John may have the LoanManager role, and that role can be granted the ApproveLoan privilege.

When John attempts to approve a loan, Pega can use this security configuration to determine whether the protected action is allowed.

Important:
Having access to a Case does not automatically mean that a user can perform every action on that Case.

Also remember that simply hiding a button in the user interface is not the same as enforcing authorization. The underlying security configuration must protect the actual capability.

Putting Everything Together

Now let's follow John from login to the point where he approves a loan.

STEP 01

Authentication

John is authenticated through Alpha Bank's identity provider.

STEP 02

Operator

Pega identifies John's Operator ID.

STEP 03

Access Group

John works in the appropriate Alpha Bank application/security context.

STEP 04

Application

John accesses the Alpha Bank Pega application.

STEP 05

Role

John has the LoanManager role.

STEP 06

Privilege

The ApproveLoan privilege protects the approval capability.

Authentication vs. Authorization

This is one of the most important distinctions to remember in Pega security.

AUTHENTICATION

Who are you?

Verifies the user's identity.

AUTHORIZATION

What can you do?

Determines what the authenticated user is allowed to access or perform.

Authentication gets you in. Authorization controls what you can do.

Role vs. Privilege

Another common question is: What is the difference between a Role and a Privilege?

Concept	Purpose	Alpha Bank Example
Role	Broader responsibility/permissions	LoanManager
Privilege	Specific protected capability	ApproveLoan

A simple mental model is:

Role → Permissions → Privilege → Protected Capability

What happens at runtime?

Suppose John clicks Approve Loan.

At a high level, the security configuration determines whether John has the required permission to perform that protected action.

John → Access Group → Roles / Permissions → Required Privilege → Approve Loan → Allow / Deny

A Practical Production Troubleshooting Example

Imagine Sarah can successfully log into Alpha Bank, but she cannot see or perform the Approve Loan action.

Instead of randomly changing rules, walk through the security chain:

1. Check Sarah's Operator record.
2. Check her active Access Group.
3. Verify the application context.
4. Check the Roles assigned to the Access Group.
5. Verify the required permissions.
6. Check whether the required Privilege is configured.
7. Check the security configuration protecting the action.
8. Check for additional restrictions such as Access Deny or other access controls.

Production tip: Don't start by changing the Flow Action or hiding/showing buttons. First identify where the security chain breaks.

The Mental Model I Use

If you remember only one thing from this article, remember this flow:

AUTHENTICATION

Who are you?

OPERATOR

Which Pega user are you?

ACCESS GROUP

Which application/security context?

APPLICATION

Which Pega application?

ROLE

What type of work can you perform?

PRIVILEGE

Can you perform this specific protected action?

KEY TAKEAWAY

Authentication identifies the user, the Operator represents the user in Pega, the Access Group establishes the application and security context, Roles define broader permissions, and Privileges provide more granular control over specific capabilities.

Pega Security Series

Part 1 — Authentication, Operator, Access Group, Roles & Privileges

Part 2 — Roles, AROs, Privileges & Access Deny

Part 3 — Case Security, Access When, ABAC & Data Security

Part 4 — SAML, SSO & Identity Providers

Part 5 — API & Integration Security

Part 6 — Pega Security Troubleshooting

PegaHelp.com · Practical Pega Architecture & Development