PEGA SECURITY SERIES · PART 3

Pega Security – Part 3: Case Security, Access When, ABAC & Data Security

Moving from role-based access to controlling exactly which cases and data a user can access.

What happens after Pega knows who you are?

In Part 1, we looked at how Pega identifies a user through Authentication, Operator ID, Access Group, Application, Roles, and Privileges.

In Part 2, we went one level deeper and looked at Access Roles, AROs, Privileges, and Access Deny.

But there is another question that comes up in real enterprise applications:

"Even though this user has access to the case type, should this particular case or this particular piece of data be visible to them?"

This is where case-level security, Access When, and Attribute-Based Access Control (ABAC) become important.

Pega Security – Part 3: How Case Security, Access When, ABAC, Access Control Policies, and data-level security work together in Pega.

Let's use a real-world example

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

Alpha Bank has a Loan Application case type. Different employees work with these cases, but they should not automatically see every loan or every piece of customer information.

Bob – Loan Officer

Creates loan applications, updates customer information, and works on applications assigned to his branch.

John – Loan Manager

Reviews and approves loan applications within his authorized region and business unit.

Sarah – Compliance Analyst

Reviews compliance information and sensitive customer data when required for regulatory checks.

Now imagine that Bob opens a loan application belonging to another branch. Should his role alone determine whether he can access it?

Not necessarily.

We may need a rule such as:

User's Branch must match Loan Application's Branch.

AND

User's Region must match Loan Application's Region.

That is no longer just a role-based decision. We are comparing attributes of the user with attributes of the case.

Case Security vs Data Security

These two are related, but they solve different problems.

Security Need	Example	Pega Mechanism
Can Bob open this case?	Bob can access only loans from his branch	RBAC + ABAC / Access Control Policy
Can Bob update this case?	Bob can update applications in his region	Update policy
Can Bob see the SSN/TIN?	Only authorized users see the full value	PropertyRead
Should the sensitive value be encrypted at rest?	Customer SSN/TIN	PropertyEncrypt

What is an Access When rule?

An Access When rule is a conditional security rule. It evaluates properties and returns whether a particular security condition is true or false.

The important point is that Access When is not simply another UI visibility condition.

It participates in authorization decisions.

Example – Alpha Bank

Access When:
OperatorID.pyOrgUnit = "LoanOperations"

You can then use that Access When in a security configuration where the result of the condition changes the authorization behavior.

Important distinction

Do not confuse:

• Visible When – controls presentation.
• Access When – participates in authorization logic.
• When rule – general reusable conditional logic.

Production reminder: Hiding a button with Visible When does not secure the underlying business action. The actual authorization must be enforced by Pega security rules.

Attribute-Based Access Control (ABAC)

ABAC becomes useful when authorization depends on attributes of the user, case, or data.

Think of it as:

User Attributes

+

Case / Data Attributes

↓

Authorization Decision

For example:

User: Bob

Bob's Branch: New York

Loan Branch: New York

Result: Access condition passes.

If the loan belongs to a California branch and Bob is restricted to New York, the same user may fail the ABAC condition.

The Pega Rule-Level Architecture

In a real Pega implementation, ABAC is not one rule. It is usually a combination of security rules working together.

1. Operator / User Attributes

↓

2. Access When

↓

3. Access Control Policy Condition

↓

4. Access Control Policy

↓

5. Read / Update / Delete / Discover / PropertyRead / PropertyEncrypt

Rule 1: Access Control Policy Condition

The Access Control Policy Condition is where we define the comparison logic used by the authorization policy.

In Dev Studio, the typical path is:

Dev Studio → Records → Security → Access Control Policy Condition → Create

Important configuration fields

• Label – name of the policy condition.
• Apply to – class to which the policy condition applies.
• Add to ruleset – ruleset where the security rule is stored.
• Conditional Logic – determines which filter logic is used.
• Policy Conditions – actual attribute comparisons.
• Pages & Classes – defines additional pages and their classes used by the condition.

Pega's documented configuration flow creates the policy condition from Records → Security → Access Control Policy Condition, defines the Apply To class and ruleset, then configures conditional logic, conditions, and Pages & Classes as required. :contentReference[oaicite:1]{index=1}

Let's configure one for Alpha Bank

Suppose Alpha Bank wants Bob to access only loan applications belonging to his branch.

Assume:

• User branch → OperatorID.pyBranch
• Loan branch → .BranchCode

The policy condition conceptually becomes:

OperatorID.pyBranch = .BranchCode

The exact implementation of the attributes depends on how the application stores operator and case security information. The important design is that the policy condition compares the appropriate user attribute against the protected object's attribute.

Pages & Classes – an important implementation detail

Suppose the policy condition needs information from the current operator. The condition may need an additional page such as:

Page name: OperatorID

Class: Data-Admin-Operator-ID

Pega's own ABAC exercise uses this pattern: an OperatorID page with class Data-Admin-Operator-ID is added on the Pages & Classes tab so operator attributes can participate in the policy condition. :contentReference[oaicite:2]{index=2}

Production design tip: If security attributes come from multiple sources, consider aggregating the required user attributes into a suitable data structure/Data Page instead of making every policy independently retrieve them.

Conditional Logic inside the Policy Condition

This is where ABAC becomes powerful.

The policy condition can use different filter logic depending on an Access When rule.

For example:

WHEN: User is a Loan Manager

→ Apply manager access logic

OTHERWISE:

→ Apply normal branch-level access logic

Pega documents conditional logic in an Access Control Policy Condition using Access When rules and filter logic. Multiple policy conditions can also be combined using Boolean logic such as AND and OR. :contentReference[oaicite:3]{index=3}

Rule 2: Access Control Policy

The Access Control Policy is where we tell Pega what type of access the policy controls.

In Dev Studio:

Dev Studio → Records → Security → Access Control Policy → Create

The important Action values

Action	What it controls	Alpha Bank example
Read	Opening/viewing the protected object	Bob can read loans from his branch
Update	Updating protected object data	Bob can update his branch's loans
Discover	Limited visibility into a case without full Read access	Show limited information in a worklist/search
Delete	Deleting the protected object	Only authorized managers can delete
PropertyRead	Visibility of individual properties	Mask SSN/TIN for unauthorized users
PropertyEncrypt	Encryption of selected property data	Encrypt customer SSN/TIN

These actions are documented by Pega for Access Control Policy configuration. In particular, PropertyRead controls property visibility, while PropertyEncrypt protects the property through encryption. :contentReference[oaicite:4]{index=4}

Build the Access Control Policy

For our Alpha Bank branch example, suppose we create:

Label: LoanBranchReadAccess

Action: Read

Apply to: Alpha-Banking-Work-LoanApplication

Permit access if: LoanBranchMatchesOperator

Here, LoanBranchMatchesOperator is the Access Control Policy Condition we created earlier.

So the architecture is:

Loan Application

↓

Access Control Policy

↓

LoanBranchMatchesOperator

↓

Access When + Attribute Comparison

↓

Allow / Deny

PropertyRead – protecting individual fields

Sometimes we don't want to hide the entire case. We only want to protect one sensitive property.

This is where PropertyRead becomes useful.

Imagine the Loan Application contains:

• Customer Name
• Account Number
• Loan Amount
• SSN / TIN
• Credit Score

Bob may legitimately need to open the loan case but may not need to see the complete SSN/TIN.

Example

Stored value: 123456789

Bob sees: ******789

Rule-level configuration

Create an Access Control Policy and select:

Action = PropertyRead

Then:

1. Set the appropriate Apply to class.
2. Specify the Permit access if policy condition.
3. Click Add Property.
4. Select the sensitive property, such as .SSN.
5. Configure the masking behavior.

Pega documents masking options such as full masking, masking all but the last N characters, or masking all but the first N characters. :contentReference[oaicite:5]{index=5}

PropertyEncrypt – encryption is a different problem

This is an important distinction:

PropertyRead

Controls what an authorized user sees.

PropertyEncrypt

Protects the property's stored representation through encryption.

For example, Alpha Bank may use PropertyEncrypt for a sensitive customer identifier.

In Dev Studio:

Access Control Policy → Action = PropertyEncrypt

Then add the property that needs encryption.

Important: PropertyEncrypt is not a substitute for PropertyRead. Encryption protects stored/transported representations, while PropertyRead controls what the user is allowed to see.

Pega's documentation also notes that PropertyEncrypt policies are unconditional for the selected properties; the policy condition is not used for PropertyEncrypt. A separate PropertyRead policy can be used to mask or restrict what users see. :contentReference[oaicite:6]{index=6}

RBAC + ABAC – how they work together

This is one of the most important concepts to understand for an LSA or Senior System Architect interview.

ABAC does not simply replace RBAC. They can work together.

RBAC

+

ABAC

↓

Authorization Decision

For example:

1. Bob's Loan Officer role gives him basic access to Loan Application cases.
2. ABAC checks whether the particular loan belongs to Bob's authorized branch.
3. If either authorization model does not permit the operation, the operation should not be allowed.

Pega documentation describes RBAC and ABAC as complementary models and explains that applicable policy conditions are combined so that the authorization requirements are satisfied together. :contentReference[oaicite:7]{index=7}

Complete Alpha Bank runtime example

Let's walk through what happens when Bob opens a loan application.

1. Bob logs in
Authentication establishes Bob's identity.

2. Pega identifies Bob's Operator ID
The request runs under Bob's security context.

3. Access Group establishes application context
Bob receives the application and access roles associated with his context.

4. RBAC checks the role-based permissions
Bob must have the required access to the Loan Application class.

5. ABAC evaluates the case attributes
The policy condition compares Bob's attributes with the loan's attributes.

6. Access Control Policy determines the operation
Read, Update, Delete, Discover, or property-level access is evaluated.

7. Sensitive properties are separately protected
PropertyRead can mask sensitive values while PropertyEncrypt protects selected properties at rest.

One of the most common mistakes

"I'll just hide the field."

This is not sufficient for sensitive information.

A UI configuration that hides a field does not automatically establish backend authorization.

For sensitive data, enforce the requirement using the appropriate Pega security mechanism, such as PropertyRead or other authorization controls.

Production troubleshooting

Imagine John should be able to open a loan application, but Pega denies access.

I would troubleshoot it from the outside in:

1
Operator

2
Access Group

3
Roles / ARO

4
Access When

5
Policy Condition

6
Access Policy

Questions I would ask during troubleshooting

• Is the user authenticated as the expected Operator ID?
• Which Access Group is active?
• Which Access Roles are assigned?
• Does the ARO provide the required class-level access?
• Is an Access Deny affecting the role?
• Is an Access When rule returning the expected result?
• Is the Access Control Policy Condition evaluating the expected attributes?
• Are the Pages & Classes definitions correct?
• Is the Access Control Policy applied to the expected class?
• Is the policy inherited from a parent class?
• Is another policy also being evaluated?
• Are the operator attributes actually populated?

Don't guess – verify the policy

Pega provides a way to verify Access Control Policies against an operator.

This is extremely useful when troubleshooting ABAC.

You can select the operator and, where applicable, the Access Group, then run the policy verification and inspect the policy-condition results.

Practical troubleshooting approach

Don't immediately change the security rule. First determine which policy condition failed and why the expected attribute value was not matched.

Pega Academy documents policy verification as a way to select an Operator ID, optionally select the Access Group, verify policies, and inspect the individual policy-condition results. :contentReference[oaicite:8]{index=8}

Performance considerations

Security rules execute on business operations, so security design also needs to consider performance.

Be careful when a policy condition requires expensive or repeated data retrieval.

For example, if a policy needs several attributes from an external system, don't design every case read to independently call that system.

Instead, consider:

• Which user attributes are actually required?
• Can they be available in the current security context?
• Can a suitable Data Page aggregate required attributes?
• Can attributes be cached safely?
• Is the policy condition evaluating simple properties rather than expensive logic?
• Does the policy apply to a high-volume class?

My production rule: Security should be strong, but the security decision itself should be designed to be predictable and inexpensive.

How I would design this in a real project

1. Start with the business requirement.
   Example: "Loan Officers can access only loans from their authorized branches."
2. Identify the user attributes.
   Branch, region, organization, clearance, manager hierarchy, etc.
3. Identify the case/data attributes.
   BranchCode, RegionCode, DataClassification, CustomerType, etc.
4. Choose the authorization model.
   Use RBAC for broad persona-based access and ABAC when access depends on attributes.
5. Create the Access When rules only where conditional logic is needed.
6. Create the Access Control Policy Condition.
   Define the actual comparison/filter logic.
7. Create the Access Control Policy.
   Decide whether the policy controls Read, Update, Delete, Discover, PropertyRead, or PropertyEncrypt.
8. Test positive and negative scenarios.
   Test users who should have access and users who should not.
9. Verify the policy in Dev Studio and test it with real case data.

Easy mental model

RBAC = What can this type of user generally do?

+

ABAC = Does this particular user qualify for this particular object?

+

PropertyRead = Which individual values can this user see?

+

PropertyEncrypt = How is sensitive property data protected at rest?

Key Takeaway

Pega security does not stop after assigning a Role or ARO.

In enterprise applications, we often need to answer more specific questions:

• Can this user access this particular case?
• Can the user update this case?
• Can the user delete it?
• Can the user discover limited information about it?
• Can the user see this sensitive property?
• Should the property be encrypted?

Access When + Access Control Policy Condition + Access Control Policy give us the rule-level foundation for attribute-based authorization, while PropertyRead and PropertyEncrypt address sensitive data at the individual-property level.

Quick Interview Summary

What is ABAC?
ABAC controls access by evaluating attributes of the user and the protected case or data.

What is an Access When rule?
It defines conditional logic that can be used as part of authorization.

What is an Access Control Policy Condition?
It defines the attribute comparison/filter logic used to determine whether a policy condition is satisfied.

What is an Access Control Policy?
It specifies the operation being controlled, such as Read, Update, Delete, Discover, PropertyRead, or PropertyEncrypt.

PropertyRead vs PropertyEncrypt?
PropertyRead controls visibility of a property, while PropertyEncrypt protects the property's stored representation through encryption.

Does ABAC replace RBAC?
No. They are complementary authorization models and can be evaluated together.

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

Practical Pega Architecture & Implementation

PegaHelp.com