Pega Security – Part 4: SAML, SSO & Identity Providers
In the previous parts of this Pega Security series, we looked at how Pega identifies a user, determines what that user can do, and controls access to cases and data.
But in a large enterprise such as a bank, there is another important question:
And how can the employee use the same corporate login instead of maintaining another Pega username and password?
This is where SAML, Single Sign-On (SSO), and Identity Providers (IdPs) come into the picture.
In this article, we will use a fictional Alpha Bank implementation to walk through the complete authentication journey — from the moment an employee opens Pega to the point where Pega creates the authenticated session and applies its normal authorization model.
Pega Security – Part 4: End-to-end SAML 2.0 SSO authentication flow showing what happens between the user, Pega, the Identity Provider, and Pega's security model.
1. Alpha Bank Scenario
Imagine Alpha Bank has thousands of employees using different enterprise applications every day.
Alpha Bank does not want employees to maintain a separate username and password for every application. Instead, the bank has a centralized Identity Provider such as Okta.
For this example, we will use Okta as the Identity Provider. This is an example enterprise architecture for understanding the Pega configuration; it does not imply that a real Alpha Bank uses Okta.
Our users are:
Branch Manager
Loan Officer
Credit Manager
Customer Service Representative
Bob needs to access the Alpha Bank Loan Application in Pega.
Instead of entering a separate Pega password, Bob should be able to access Pega using his existing corporate identity.
Bob should be able to open Pega, authenticate through Alpha Bank's corporate Identity Provider, and then receive the appropriate Pega security context.
2. What Are SAML, SSO, and an Identity Provider?
SAML
SAML stands for Security Assertion Markup Language.
SAML allows an Identity Provider to communicate authentication information to an application.
In our example:
Single Sign-On (SSO)
SSO means the employee can use an existing enterprise authentication session rather than maintaining a separate login for every application.
For Bob, the experience can be as simple as:
Identity Provider
The Identity Provider (IdP) is responsible for authenticating the user.
In our Alpha Bank example:
- Okta = Identity Provider (IdP)
- Pega = Service Provider (SP)
- Bob = User
3. Alpha Bank SAML Architecture
At a high level, the architecture looks like this:
Service Provider (SP)
Identity Provider (IdP)
→ Operator ID
→ Access Group
→ Authorization
The important point is that SAML handles authentication. Once authentication succeeds, Pega's own authorization model still determines what Bob is allowed to access and perform.
4. End-to-End SAML Login Flow
Let's walk through exactly what happens when Bob accesses the Alpha Bank Pega application.
Step 1 – Bob accesses Pega
Bob opens the Alpha Bank Pega URL from his browser.
At this point, Bob is not yet authenticated to Pega.
Step 2 – Pega initiates the SAML login
Pega determines that the requested authentication service is based on SAML 2.0.
Pega uses its authentication infrastructure, including the PRAuth authentication gateway, to initiate the authentication process.
The SAML authentication service provides the configuration needed to create the SAML authentication request.
Step 3 – Browser is redirected to Okta
The browser is redirected to the Okta SSO URL with the SAML authentication request.
Now the browser is communicating with the Identity Provider.
Step 4 – Okta authenticates Bob
Okta authenticates Bob using the organization's configured authentication mechanisms.
This can include:
- Username and password
- MFA
- Corporate authentication policies
- Other Identity Provider policies configured by the organization
Once Bob is successfully authenticated, Okta prepares the SAML assertion for Pega.
Step 5 – Okta sends the SAML response to Pega
Okta sends a signed SAML Response containing the SAML assertion to Pega's configured Assertion Consumer Service (ACS) endpoint.
The assertion can contain identity information such as:
email = bob@alphabank.com
firstName = Bob
lastName = Smith
department = Lending
employeeType = Employee
branch = NYC001
role = LoanOfficer
The exact attributes and claim names depend on how the Identity Provider and Pega application are configured.
Step 6 – Pega validates the SAML response
Pega does not simply trust any SAML response that reaches the ACS endpoint.
Pega validates the SAML response using the configured SAML trust and validation information.
The validation process can include checks such as:
- Digital signature
- Issuer
- Audience
- Assertion conditions and time validity
- Destination / ACS endpoint
For example, Pega can verify that the assertion was signed using the trusted certificate configured for the Identity Provider.
Step 7 – Pega maps the identity to an Operator ID
After validating the assertion, Pega needs to determine which Pega user the authenticated identity represents.
A common approach is to map a SAML identity attribute such as NameID to the Pega Operator ID.
For example:
↓
Pega Operator ID: bob@alphabank.com
Depending on the configuration, Pega can use an existing Operator or create an Operator for a new authenticated user when provisioning is configured.
Step 8 – Pega establishes the authenticated session
Pega now creates the authenticated requestor/session context for Bob.
The appropriate Access Group and security context are established, and Bob can continue into the Pega application.
From this point forward, the normal Pega authorization model takes over.
5. Where Does the Pega Authentication Service Fit?
One of the important Pega concepts in this architecture is the Authentication Service.
Authentication Service rules are used to configure how Pega authenticates users.
In Pega, the Authentication Service configuration is represented by the Data-Admin-AuthService rule type.
Authentication Service tells Pega how the user should be authenticated.
In our Alpha Bank implementation, the Authentication Service is configured for SAML 2.0.
Pega's PRAuth authentication gateway is involved in routing authentication requests through the configured authentication mechanism.
6. What Do We Configure Before SAML Login Works?
SAML authentication requires configuration on both sides:
Pega – Service Provider
- Create/configure SAML 2.0 Authentication Service
- Import IdP metadata or configure the required information
- Configure the Service Provider identity
- Configure Operator ID mapping
- Configure provisioning if required
- Configure access context as required
Okta – Identity Provider
- Create the SAML application
- Configure the Pega ACS URL
- Configure the Audience / Entity ID
- Configure NameID
- Configure attribute statements
- Assign users or groups to the application
- Provide/download IdP metadata when required
7. SP Entity ID and ACS URL
Two terms that frequently appear in SAML configuration are Entity ID and ACS URL.
SP Entity ID
The Entity ID identifies the Pega Service Provider in the SAML trust relationship.
Okta needs to know which application/service provider the SAML assertion is intended for.
ACS URL
ACS stands for Assertion Consumer Service.
This is the endpoint where the Identity Provider sends the SAML response after authentication.
https://<your-pega-server>/prweb/PRRestService/WebSSO/SAML/v2/AssertionConsumerService
The exact values used by an implementation depend on the Pega environment and Identity Provider configuration.
8. What Is Inside the SAML Assertion?
Think of the SAML assertion as the Identity Provider's statement to Pega:
For our Alpha Bank example, the assertion could contain information such as:
| Attribute | Example Value | Possible Use |
|---|---|---|
| NameID | bob@alphabank.com | Operator mapping |
| bob@alphabank.com | User identity | |
| department | Lending | Authorization / ABAC |
| branch | NYC001 | Conditional access |
| role | LoanOfficer | Application/security context |
The exact claims are implementation-specific. The important concept is that Pega can consume identity information from the authenticated request and use the appropriate attributes in subsequent processing.
9. What Happens to the SAML Attributes Inside Pega?
One of the useful Pega artifacts shown in the architecture is the D_SAMLAssertionDataPage.
During authentication, this data page can expose information from the SAML assertion, such as NameID and other configured attributes.
For example, during Bob's authentication, the data could look conceptually like this:
.email bob@alphabank.com
.firstName Bob
.lastName Smith
.department Lending
.employeeType Employee
.branch NYC001
This is especially useful when the organization wants identity attributes from the enterprise Identity Provider to participate in the Pega authentication and authorization design.
10. From SAML Identity to Pega Operator ID
Authentication through Okta does not mean Pega suddenly has no concept of an Operator.
Pega still needs an authenticated user identity that it can use for application security.
In our example:
bob@alphabank.com
bob@alphabank.com
Access Group → Roles → AROs → Privileges
The Operator record is represented by Data-Admin-Operator-ID.
The Operator provides the identity that Pega uses when applying its authorization model after authentication.
11. What Happens in pxRequestor?
After successful authentication, Pega establishes an authenticated requestor/session context.
The pxRequestor context represents information about the authenticated user/requestor and the current Pega session.
Conceptually, for Bob we could have values such as:
.pzAccessGroup AlphaBank-Lending
.pzDefaultAccessRole AlphaBank:LoanOfficer
.pyAuthenticationType SAML2
.pySource Okta
The exact properties and values depend on the implementation and Pega version/configuration, but the important idea is:
12. SAML Authentication Does NOT Replace Pega Authorization
This is probably the most important concept in this entire article.
Authentication
Who are you?
SAML + Identity Provider
Authorization
What can you do?
Access Groups + Roles + AROs + Privileges + Case/Data Security
So after Bob successfully authenticates through Okta, Pega still needs to determine what Bob is allowed to do.
13. The Pega Security Chain After Authentication
The post-authentication journey can be represented as:
User
Group
Roles
Privileges
Access Deny
Data Security
Application
This connects directly to what we discussed in Parts 1, 2, and 3.
14. Alpha Bank – What Happens to Bob After Login?
Let's say Bob is a Loan Officer.
Bob successfully authenticates through Okta. Pega maps his identity to the Operator ID bob@alphabank.com.
Now Pega can establish Bob's security context:
- Authenticated identity
- Operator ID
- Access Group
- Application context
- Access Roles
- AROs
- Privileges
- Case and data security
For example, Bob may have:
Access Group: AlphaBank-Lending
Role: AlphaBank:LoanOfficer
Privilege: CreateLoan / SubmitLoan
Branch: NYC001
Bob may therefore be allowed to create and work on loan applications, while Sarah, who is a Credit Manager, may have additional privileges such as approving a loan.
The Identity Provider authenticated both users. Pega's authorization model determines what each user can actually do.
15. SAML Attributes Can Also Support ABAC
Now let's connect Part 4 with the ABAC concepts we discussed in Part 3.
Suppose Bob's SAML identity contains:
Department = Lending
Role = LoanOfficer
Bob opens a Loan Application whose branch is also NYC001.
An ABAC design can use this type of user and object attribute comparison as part of the access decision.
This gives us a useful connection:
Establishes external identity
Represents user in Pega
Defines general permissions
Applies attribute-based conditions
16. Key Pega Artifacts Involved at Runtime
The following artifacts are useful to understand when troubleshooting or explaining this architecture in a Pega interview.
| Artifact / Rule | Purpose |
|---|---|
| PRAuth Servlet | Authentication gateway for authentication processing |
| Data-Admin-AuthService | Authentication Service configuration, including SAML authentication |
| D_SAMLAssertionDataPage | Exposes SAML assertion information during authentication |
| Data-Admin-Operator-ID | Pega Operator record representing the authenticated user |
| pxRequestor | Authenticated requestor/session context |
| Access Group | Application and security context |
| Access Role | Collection of permissions, privileges, and ARO relationships |
| Access Role Object (ARO) | Associates roles with access to application classes/data |
| Privilege | Controls specific actions or protected functionality |
| Access When / Access Deny | Conditional and explicit security controls |
| Access Control Policy | ABAC-based row/property-level security |
17. Authentication vs Authorization – The Complete Picture
Let's put everything we have learned so far together.
User → Identity Provider → SAML → Pega Authentication Service → Operator ID → Session
Operator → Access Group → Application → Roles → AROs → Privileges → Access When / Access Deny → ABAC / Data Security
This is why authentication and authorization should not be treated as the same thing.
18. SAML Troubleshooting in Pega
One of the easiest ways to troubleshoot SAML is to first identify where the flow stopped.
Check the Authentication Service configuration, SAML configuration, SSO URL, and related environment/configuration issues.
Check certificate/signature, issuer, audience, ACS/destination, assertion conditions, and timestamps.
Now stop troubleshooting SAML and inspect the Pega authorization chain.
19. If SAML Works but Bob Has the Wrong Access
Suppose Bob successfully logs in through Okta but cannot open a Loan Application.
Do not immediately start debugging the SAML assertion again.
Follow the Pega security chain:
↓
Access Group
↓
Access Roles
↓
ARO / Privileges
↓
Access When / Access Deny
↓
ABAC / Access Control Policy
↓
Case / Data Access
This distinction is extremely useful in production troubleshooting.
20. Common SAML Configuration Issues
| Issue | What to Check |
|---|---|
| Redirect does not happen | Authentication Service and SAML configuration |
| Wrong SSO URL | Identity Provider SSO endpoint |
| Audience mismatch | IdP Audience / SP Entity ID |
| Signature validation failure | IdP certificate and trust configuration |
| User cannot be mapped | NameID / identity attribute and Operator mapping |
| Login succeeds but access is wrong | Operator, Access Group, Roles, AROs, Privileges, ABAC |
21. SAML vs OpenID Connect
Pega supports modern enterprise authentication approaches including SAML 2.0 and OpenID Connect (OIDC).
| SAML | OpenID Connect |
|---|---|
| XML-based | OAuth 2.0-based identity layer |
| Uses SAML assertions | Uses ID tokens, commonly JWT-based |
| Widely used for enterprise SSO | Common in modern web/cloud identity architectures |
| Supports federated authentication | Supports federated authentication |
The appropriate protocol depends on the organization's Identity Provider, architecture, security standards, and application requirements.
22. Alpha Bank – Complete Pega Security Journey
We can now connect all four parts of the Pega Security series.
Bob → Okta → SAML → Pega
SAML identity → Pega Operator ID
Operator → Access Group → Application
Access Roles → AROs → Privileges
Access When → Access Deny
ABAC → Access Control Policy → Property/Row-level security
So the complete journey is:
23. How to Explain This in a Pega Interview
Sample interview answer:
"In an Alpha Bank implementation, I can configure Pega as the SAML Service Provider and an enterprise Identity Provider such as Okta or Microsoft Entra ID as the Identity Provider. When Bob accesses the Pega application, Pega initiates the SAML authentication flow and redirects the browser to the Identity Provider. The IdP authenticates Bob and sends a signed SAML assertion back to Pega's ACS endpoint. Pega validates the assertion and maps an identity attribute such as NameID to the Pega Operator ID. Once the user is authenticated, Pega establishes the requestor and Access Group context. From there, normal Pega authorization takes over — Access Roles, AROs, Privileges, Access When, Access Deny, and ABAC or data-level policies determine what Bob can access and what actions he can perform. So SAML handles federated authentication and SSO; it does not replace Pega's authorization model."
24. Easy Way to Remember It
How does Pega trust the external identity?
Who is this user inside Pega?
What can this type of user generally do?
Does this user qualify for this particular case or data?
What access should explicitly be denied?
Key Takeaway
SAML and SSO solve the enterprise authentication problem: who is the user?
Pega then continues with its own security model to answer: what can this user access and what can this user do?
In our Alpha Bank example, the complete flow is:
Bob → Okta → SAML Assertion → Pega Authentication Service / PRAuth → Operator ID → Access Group → Roles / AROs / Privileges → Access When / Access Deny → ABAC / Data Security → Alpha Bank Pega Application
Understanding this complete chain makes it much easier to design, explain, and troubleshoot enterprise Pega security.
No comments:
Post a Comment