Pega Security – Part 2: Roles, AROs, Privileges & Access Deny
In Part 1, we followed the user journey from Authentication to Operator, Access Group, Application, Roles, and Privileges. Now let's go one level deeper and see how Pega actually controls what a role can access and what it is not allowed to do.
In a real Pega application, simply assigning a user a role is not enough. Pega needs to know what that role can access, what actions it can perform, and in some situations, what must be explicitly denied.
This is where Access Roles, Access of Role to Object (ARO), Privileges, and Access Deny become important.
The simple idea:
A Role defines who the user is from an authorization perspective. AROs define what that role can do with a class. Privileges protect specific rules or capabilities. Access Deny provides an explicit restriction when needed.
Let's use the same Alpha Bank example from Part 1.
Alpha Bank Example
Alpha Bank has a Pega application that manages loan applications. Different employees have different responsibilities.
For example:
Loan Officer
Loan Manager
Compliance Analyst
Bob may create and update loan applications. John may review and approve them. Sarah may have access to compliance information but should not automatically receive loan approval authority.
So how does Pega enforce these differences?
Pega Security – Part 2: How Access Roles, AROs, Privileges, and Access Deny work together to control access in Pega.
Role-Based Access Control in Pega
Pega uses Role-Based Access Control (RBAC) to define authorization based on the user's assigned access roles.
The important point is that the role itself is only part of the picture. The role is associated with access-control records that determine what users assigned to that role can do.
1. Access Role — Define the User's Authorization Role
An Access Role represents a group of users who need a particular set of authorization rules.
In Alpha Bank, we could have roles such as:
The Access Role becomes the foundation for the access records that determine what members of that role can access.
Access Role = the authorization persona.
2. ARO — Access of Role to Object
ARO stands for Access of Role to Object.
This is one of the most important concepts in Pega RBAC. An ARO defines access permissions for a role against instances of a particular class.
Think about the relationship this way:
For example, Alpha Bank's AlphaBank:LoanOfficer role may have permissions on the Loan Application Case Type.
Those permissions can control actions such as opening, updating, creating, deleting, reporting, or viewing history, depending on the application's security design.
ARO Example: Loan Application
Suppose Alpha Bank wants the following behavior:
- Loan Officers can open loan applications.
- Loan Officers can update loan applications.
- Loan Managers can review loan applications.
- Loan Managers can approve loans.
- Compliance Analysts can review compliance information.
The ARO configuration becomes part of the authorization model that enforces these permissions.
ARO controls access to objects and their actions. It is different from a Privilege, which protects a specific Rule or capability.
3. Privilege — Protect a Specific Capability
A Privilege provides more granular authorization. It can be associated with certain Pega Rules to control who can use or execute that Rule or capability.
Let's say Alpha Bank has a Flow Action called:
We can protect that capability with a privilege such as:
John has the LoanManager role. That role is granted the required privilege through the appropriate access-control configuration.
When John attempts to perform the protected action, Pega can verify whether he has the required privilege.
ARO vs. Privilege
This is one of the most common areas of confusion when learning Pega security.
| Security Concept | Main Purpose | Alpha Bank Example |
|---|---|---|
| Access Role | Defines the authorization persona | LoanManager |
| ARO | Controls access to a class/object | Loan Application access |
| Privilege | Protects a specific Rule/capability | ApproveLoan |
4. Access Deny — When You Need an Explicit Restriction
Sometimes granting permissions is not enough. There may be a situation where a user belongs to a role that normally has access, but a particular business or regulatory requirement says that access must be explicitly restricted.
This is where Access Deny can be used.
Explicitly restricts an action for the applicable role and class when the security design requires a denial.
Access Deny Example: Compliance Restriction
Imagine that Alpha Bank has a Loan Manager role with broad access to loan applications.
However, a specific group of users should not be allowed to view certain sensitive information or perform a particular operation under defined business conditions.
Instead of redesigning the entire role, the application can use an explicit access-denial rule where appropriate.
The important point is that Access Deny is intended for explicit restrictions in the authorization design. It should not be used simply because the role model has not been designed properly.
ARO vs. Access Deny
Grant / control access
Defines permissions for a role against instances of a class.
Explicit restriction
Explicitly restricts authorization for the applicable role and class.
For the same role and class combination, Pega evaluates Access Deny as an explicit restriction when configured. Current Pega guidance also notes that Access Deny does not override privileges granted through AROs, so privilege design should be handled separately.
Understanding the ARO Access Levels
ARO permissions can be associated with production-level values. The values range from 0 through 5.
This allows access settings to behave differently depending on the production level of the environment.
What Happens When John Clicks "Approve Loan"?
Let's bring everything together.
John is a Loan Manager and opens a loan application. He clicks Approve Loan.
If the required authorization is present, the action can proceed. If the required security control is not satisfied, Pega prevents the protected operation.
Don't Confuse UI Visibility with Security
This is a common mistake in real projects.
Suppose the Approve Loan button is hidden from Bob because Bob is a Loan Officer.
That improves the user experience, but hiding the button by itself should not be considered the complete authorization mechanism.
UI visibility controls what the user sees. Security controls what the user is actually allowed to do.
Production Troubleshooting: "Why Can't This User Access the Case?"
Imagine Sarah tells you:
Don't immediately change the Case Type or add another role. Walk through the security chain.
- Check Sarah's Operator ID.
- Check her active Access Group.
- Identify the Access Roles assigned to that Access Group.
- Check the relevant ARO for the Case Type/class.
- Check the permission being evaluated, such as opening or updating the Case.
- Check for an applicable Access Deny configuration.
- If the issue is a specific Rule or capability, check the required Privilege.
- Check any additional access conditions configured for the application.
A Practical Design Approach
When designing security for a new Pega application, I like to start with the business personas rather than immediately creating security rules.
This keeps the security model easier to understand and reduces the temptation to solve every security problem with another role or another rule.
In Pega RBAC, the Access Group provides the security context, Access Roles define the authorization persona, AROs control access to objects of a class, Privileges protect specific Rules or capabilities, and Access Deny provides an explicit restriction when required.
Quick Interview Summary
What is an ARO?
Access of Role to Object. It defines authorization settings for a role
against instances of a particular class.
What is a Privilege?
A privilege provides granular authorization for specific Rules or
protected capabilities.
What is Access Deny?
An explicit restriction used to deny access for the applicable role and
class when the security design requires it.
What is the difference between ARO and Privilege?
ARO controls access to objects and their actions, while a Privilege
protects a specific Rule or capability.
No comments:
Post a Comment