Security Architecture for the Nexus Banking Application
How Authentication, Authorization, RBAC, ABAC, Case Security, Data Security, Integration Security, and Audit work together in Alpha Bank Nexus
In the previous parts of this series, we designed the major building blocks of the Nexus banking application for Alpha Bank. We looked at the application architecture, Case Types, Data Types, integrations, and inheritance.
Now we need to answer one of the most important architectural questions:
Security in Pega is not implemented by a single Rule Type or one configuration. It is a collection of complementary layers. Authentication establishes identity, while authorization determines what an authenticated user can access or perform. Pega supports multiple authorization models, including Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), Client-Based Access Control (CBAC), and Basic Access Control (BAC). These models can complement each other rather than representing mutually exclusive choices.
In this article, we will build the complete security architecture for our Alpha Bank Nexus application and trace a request from the user all the way through authentication, authorization, Case security, data security, integrations, and audit.
Pega Application Architecture – Part 6: Authentication, authorization, RBAC, ABAC, Case security, data security, integration security, and audit in Alpha Bank's Nexus application.
1. Start With the Security Architecture, Not the Rules
Before creating Access Roles, Privileges, Access Control Policies, or Access Groups, we first identify what needs to be protected.
For Alpha Bank, we can ask:
- Who can log in to Nexus?
- Which employees can access the application?
- Which Case Types can each persona access?
- Which individual Cases can a user open?
- Which actions can the user perform?
- Which customer information can the user see?
- Which sensitive properties must be protected?
- Which users can approve loans?
- Which users can perform KYC or fraud operations?
- Which external systems can Nexus communicate with?
- How are security-sensitive actions audited?
- How are administrators and developers restricted?
Pega's authorization design guidance recommends defining the required roles, privileges, and attributes first and then deciding which authorization mechanisms are needed. Least-privilege access should be part of the design rather than something added after development.
2. The Security Layers of Nexus
A useful way to understand our architecture is to separate security into distinct questions:
Who are you?
Which application can you use?
What are you allowed to do?
Which Cases can you access?
Which information can you see or modify?
Which external systems can Nexus access?
What happened?
3. Authentication — Who Are You?
Authentication answers a simple question:
In an enterprise banking environment, Nexus would commonly participate in an enterprise identity architecture rather than maintaining an independent password system for every user.
Example Alpha Bank flow
The exact authentication protocol depends on Alpha Bank's enterprise identity architecture. Pega provides Authentication Service configuration for supported authentication mechanisms and maps the authenticated identity into Pega's operator model.
4. Operator ID — The Pega Identity
Once the user is authenticated, Pega works with an Operator ID. The Operator record provides the Pega representation of the user and participates in determining the user's runtime security context.
Conceptually:
↓
Operator ID
↓
Access Group
↓
Application / Application Version
↓
Access Roles
This is one of the most important chains to understand when troubleshooting Pega security.
5. Access Group — Where the User Enters the Application
An Access Group is a central part of the runtime authorization context. It associates users with Access Roles and provides the application context under which the user works.
For example, Alpha Bank could have conceptual Access Groups such as:
- AlphaBank-Branch
- AlphaBank-Credit
- AlphaBank-KYC
- AlphaBank-Fraud
- AlphaBank-Operations
- AlphaBank-Admin
These names are architectural examples. The actual names should follow the project's naming standards.
Example
↓
Operator ID: Mary
↓
Access Group: AlphaBank-Credit
↓
Nexus Application
↓
Credit Manager Access Role
6. Role-Based Access Control — RBAC
RBAC answers:
Pega's RBAC model uses several Rule Types that work together:
- Access Group
- Access Role
- Access of Role to Object (ARO)
- Access Deny
- Privilege
- Class
- Access When, where conditional authorization is required
Pega describes RBAC as supporting class-wide actions, record-level actions, and rule-specific actions controlled through privileges.
7. RBAC Rule-Level Architecture
For example, suppose Alpha Bank has the following Case Type:
The Credit Analyst role might receive access to open and update loan Cases, while a Credit Manager may additionally receive the privilege required to approve a loan.
8. Security Personas in Alpha Bank
Security architecture should start with business personas rather than with Rule Types.
| Persona | Typical Responsibility | Example Nexus Access |
|---|---|---|
| Customer Service | Customer support | Customer maintenance |
| Branch Employee | Branch operations | Accounts and customer operations |
| Credit Analyst | Credit analysis | Loan review |
| Credit Manager | Loan approval | Approval actions |
| KYC Analyst | Identity verification | KYCReview |
| Fraud Analyst | Fraud investigation | FraudReview |
| Operations Manager | Operational oversight | Operational Cases and reporting |
| Nexus Administrator | Application administration | Administrative functions |
9. Case Security — Which Cases Can You Access?
Having access to the Nexus application does not mean that a user should be able to open every Case in the system.
Consider the following Case:
CustomerID = C12345
BranchCode = NY001
LoanAmount = $500,000
RiskRating = High
The security question may not simply be:
"Is Bob a Credit Analyst?"
We may also need to determine whether Bob is permitted to access this particular Case based on the business context.
This is where conditional authorization and ABAC become important.
10. Action Security — Which Actions Can You Perform?
Case access and action access are different security decisions.
Bob may be allowed to open a Loan Application but not approve it.
- Open Case ✓
- Review application ✓
- Add analysis ✓
- Approve loan ✕
- Open Case ✓
- Review application ✓
- Add analysis ✓
- Approve loan ✓
A Privilege can be used when a specific Rule or Rule component must only be executable by appropriately authorized users.
11. Privilege-Based Security
Consider the Loan Application approval action:
"Approve Loan"
↓
Required Privilege
"ApproveLoan"
↓
Access Role / ARO
CreditManager
Rule-level implementation
- Create a Privilege such as ApproveLoan.
- Associate the Privilege with the appropriate Rule or Rule component.
- Grant the Privilege through the appropriate Access Role / ARO.
- Associate that Access Role with the appropriate Access Group.
- Ensure the intended operators receive that Access Group.
The exact configuration location can vary with the Pega version and Rule Type, but the architectural relationship remains the same.
12. Access When — Conditional Security
Sometimes a simple role is not enough.
An Access When Rule can provide conditional authorization based on the current object's data.
For example:
Question: Does this Case belong to the user's permitted branch or business context?
Access When should not be treated as a replacement for RBAC. It is a mechanism for adding conditional access logic where the access outcome depends on the particular object or its properties.
13. Attribute-Based Access Control — ABAC
RBAC is useful when access is primarily determined by a user's role. But banking applications frequently require more contextual decisions.
ABAC allows access decisions to consider attributes of the user and the object being protected.
Pega's ABAC model uses Access Control Policy and Access Control Policy Condition Rules. The policies can control actions such as Read, Update, Delete, Discover, Property Read, and Property Encrypt.
14. Alpha Bank ABAC Example
Suppose Mary is a Credit Manager associated with a particular business region. A Loan Application contains:
- BranchCode
- Region
- LoanAmount
- RiskRating
- CustomerSegment
The authorization decision can consider both Mary's attributes and the Case's attributes.
This is particularly useful when the same Case Type contains records with different security requirements.
15. RBAC + ABAC — They Work Together
One of the most important concepts is that ABAC does not simply replace RBAC. Pega describes ABAC as complementary to RBAC.
+
ABAC conditions are satisfied
=
Access is granted
Therefore, when troubleshooting a security issue, do not check only the Access Role. If ABAC policies are configured, they also need to be considered.
16. Data Security — Protecting Banking Information
The user may be authorized to open a Case while still being restricted from seeing certain properties inside that Case.
Consider our Customer data:
├── CustomerID
├── CustomerName
├── Address
├── DateOfBirth
├── SSN
├── AccountNumber
├── CreditScore
└── RiskRating
Different personas may need different levels of visibility.
| Data | Customer Service | Credit Analyst |
|---|---|---|
| Customer Name | Allowed | Allowed |
| Address | Allowed | Allowed |
| SSN | Restricted | Restricted |
| Credit Score | Restricted | Allowed |
| Risk Rating | Restricted | Allowed |
17. PropertyRead — Protecting Individual Properties
A common misconception is that hiding a field on a screen makes that field secure.
If a property requires authorization, the security control should be implemented at the appropriate authorization/data-security layer rather than relying only on a visible/hidden condition in the UI.
Pega's ABAC model includes Property Read as a mechanism for restricting access to specific properties of records that the user can otherwise access.
18. PropertyEncrypt — Protecting Sensitive Data
Some banking properties require stronger protection because they contain sensitive information.
Examples may include:
- Personally identifiable information
- Account-related sensitive information
- Identity information
- Security-related attributes
- Other regulated or confidential information
Pega provides Property Encrypt as part of the ABAC/data-security model. Encryption strategy should also be aligned with Alpha Bank's enterprise encryption, key-management, compliance, and data-retention standards.
19. Basic Access Control — Protecting Application Requests
Another layer often overlooked is Basic Access Control.
Pega describes Basic Access Control as protection against unauthorized requests originating from the UI/application layer. It provides additional request verification for application-layer interactions.
This is important because an application should not assume that a user can only invoke functionality through the visible UI.
20. Integration Security
Our Part 4 architecture established that Nexus communicates with multiple enterprise systems.
For example:
Accounts / Transactions
Identity Verification
Screening
Credit Information
Card Services
Document Storage
Each integration should have its own security design.
Typical integration security concerns
- Authentication mechanism
- Authorization
- TLS and certificate management
- OAuth tokens or other credentials
- API keys where applicable
- Service identities
- Secrets management
- Timeout handling
- Retry behavior
- Audit and correlation IDs
21. Nexus Integration Security Flow
Notice that Pega's internal authorization and the external system's authorization are separate security boundaries.
22. Security Must Follow the Application Architecture
Our Nexus architecture uses Alpha Bank's application and class structure. Security rules should respect those boundaries.
The application is called Nexus, but Nexus does not need to appear in the class namespace. The class structure represents Alpha Bank's enterprise/business ownership model.
23. Security Across Our Nexus Case Types
| Case Type | Primary Personas | Security Considerations |
|---|---|---|
| CustomerOnboarding | Branch, KYC | PII, identity documents, KYC |
| AccountOpening | Branch, Operations | Account information, approvals |
| LoanApplication | Credit Analyst, Credit Manager | Credit data, approval privilege |
| KYCReview | KYC Analyst | Identity information |
| FraudReview | Fraud Analyst | Sensitive investigation data |
| CardRequest | Branch, Operations | Card and account information |
| CustomerMaintenance | Customer Service | PII and customer profile changes |
24. Separation of Duties
Banking applications frequently require separation between preparation, review, and approval.
For our Loan Application:
The architecture should not depend only on the UI to enforce this separation. The authorization model must enforce the appropriate action permissions.
25. Developer and Administrator Security
Security architecture applies to application developers and administrators too.
A production Nexus environment should not automatically give every developer unrestricted access to production data or administrative capabilities.
Typical personas may include:
- Application Developer
- Senior System Architect
- Business Architect
- Security Administrator
- System Administrator
- Production Support
- Operations
Each role should receive only the access needed to perform its responsibilities. This follows the principle of least privilege.
26. Security for Background Processing
Not every action in Nexus is performed directly by a human user.
Examples include:
- Scheduled KYC refresh
- AML screening
- Document processing
- Notifications
- Queue processing
- Data synchronization
- Batch processing
These processes also need an appropriate security context and should not automatically receive broad interactive-user privileges.
27. Audit — What Happened?
Authentication and authorization answer whether an operation should be allowed. Audit and monitoring help answer what actually happened.
Depending on the enterprise requirements, useful audit information can include:
- User identity
- Case identifier
- Action performed
- Timestamp
- Security decision
- Administrative changes
- Integration activity
- Error or security events
Logging should also be designed carefully so that passwords, tokens, secrets, and unnecessary sensitive customer information are not exposed in logs.
28. Complete Nexus Security Runtime Flow
Now let's put everything together.
29. Think of Security as Multiple Decisions
When troubleshooting a security problem, ask these questions in order:
- Was the user authenticated?
- Which Operator ID is being used?
- Which Access Group is active?
- Which Application and version are being used?
- Which Access Roles are associated with the Access Group?
- Does the role have the required ARO access?
- Is there an Access Deny rule?
- Does the operation require a Privilege?
- Is an Access When condition involved?
- Is ABAC configured for the Case or data?
- Is Property Read restricting the property?
- Is the request being blocked by another security layer?
- Is the integration itself enforcing another authorization boundary?
This approach is much more effective than simply saying: "The user doesn't have access."
30. Common Security Architecture Mistakes
UI visibility should not be treated as the authorization boundary.
This defeats least-privilege design.
Some requirements depend on user and Case attributes and may require ABAC or conditional access.
Centralized Pega authorization mechanisms should be considered where appropriate.
Credentials and secrets require secure enterprise configuration and management.
Scheduled and asynchronous processes also need a controlled security context.
These are related but different authorization decisions.
Sensitive operations need appropriate traceability and monitoring.
31. Rule-Level Security Checklist
Before moving a Nexus Case Type into production, the security design should answer the following:
| Security Area | Questions |
|---|---|
| Authentication | How is the user authenticated? |
| Operator | Which Operator ID represents the user? |
| Access Group | Which application context is active? |
| Access Role | Which business permissions are granted? |
| ARO | Which class/object operations are allowed? |
| Access Deny | Are any operations explicitly restricted? |
| Privilege | Are sensitive Rules/actions privilege-controlled? |
| Access When | Does access depend on Case data? |
| ABAC | Do user/object attributes affect access? |
| Property Security | Are sensitive properties protected? |
| Integration | Are external APIs securely authenticated and authorized? |
| Audit | Can sensitive actions be traced appropriately? |
32. Troubleshooting Security in Nexus
Problem: User cannot open a Case
Check:
- Operator ID
- Active Access Group
- Access Roles
- ARO configuration
- Access Deny rules
- Access When conditions
- ABAC policies
- Case class and inheritance
Problem: User can open the Case but cannot perform an action
Check:
- Flow Action configuration
- Required Privilege
- Access Role
- ARO
- Access When
- Any ABAC restrictions
Problem: User can open the Case but cannot see a property
Check:
- Property-level security
- Property Read policy
- ABAC configuration
- Data object security
- UI configuration separately, if applicable
The important point is that the troubleshooting path should follow the security architecture rather than randomly changing Rules.
33. The Security Mental Model for Pega Architects
↓
WHERE CAN YOU GO?
↓
WHAT CAN YOU DO?
↓
WHICH CASE CAN YOU ACCESS?
↓
WHICH ACTION CAN YOU PERFORM?
↓
WHICH DATA CAN YOU SEE?
↓
WHICH EXTERNAL SYSTEM CAN YOU CALL?
↓
WHAT SHOULD BE AUDITED?
34. Complete Alpha Bank Nexus Security Architecture
35. Security Principles for Nexus
Give users and processes only the access required for their responsibilities.
Do not rely on one security mechanism.
Separate sensitive business responsibilities such as preparation and approval.
Use Pega's security mechanisms rather than duplicating authorization logic throughout the application.
Apply appropriate property, record, encryption, and access controls.
Treat every external system as a separate security boundary.
Sensitive actions and security events should have appropriate traceability.
Security requirements should be defined before implementation rather than added at the end.
36. How Would You Explain This in a Pega Architecture Interview?
Example answer:
"For our Alpha Bank Nexus application, I would design security as a layered architecture. Authentication establishes the user's identity through the enterprise identity provider and Pega Authentication Service. The Operator ID and Access Group establish the user's Pega runtime context and application access. RBAC then uses Access Roles, AROs, Access Deny rules, and Privileges to control what the user's role can do. For requirements that depend on the user or Case attributes, I would complement RBAC with ABAC using Access Control Policies and Policy Conditions. We would separately protect Case access, individual actions, and sensitive properties. Integration endpoints would have their own authentication and authorization boundaries. Finally, security-sensitive activity would be appropriately audited and monitored. The goal is least privilege, separation of duties, defense in depth, and clear ownership of each security decision."
Key Takeaway
Security architecture in Pega is much more than creating an Access Group.
In our Alpha Bank Nexus application, security starts with authentication and continues through application access, RBAC, privileges, Case security, ABAC, property-level security, integration security, and audit.
The goal is simple: give the right person the right access to the right Case, the right action, and the right data — and protect everything else.
Pega Application Architecture Series
Pega References
The security concepts in this article are based on Pega's authorization and security documentation. Exact configuration screens and Rule Forms can vary by Pega Platform version.
Pega Application Architecture Series
Part 6 — Security Architecture
No comments:
Post a Comment