Security in Pega is the set of controls that decide who can sign in, what they can see and do once they are in, and how the platform protects data and rules along the way. It is not one feature. It is a stack of layers, and a good Pega architect can name each layer and say which rule type configures it.
The four layers of Pega security
| Layer | Question it answers | Main rule types |
|---|---|---|
| Authentication | Who are you? | Operator ID, Authentication Service, Authentication Profile (for outbound calls) |
| Authorization | What may you do? | Access Group, Access Role Name, Access of Role to Object (ARO), Access Deny, Privilege |
| Attribute and row level control | Which records and fields may you see? | Attribute-based access control (ABAC), Access When, property-level security |
| Platform hardening | Can the system itself be abused? | Rule security mode, Content Security Policy, encryption of properties, Security Checklist |
Authentication: proving identity
A user or a calling system must prove who it is before anything else happens. In Pega this is handled by an Operator ID record with a password, or by an Authentication Service that hands the job to an outside identity provider such as SAML, OAuth 2.0, OpenID Connect or LDAP. Most enterprise projects use single sign-on, so Pega never stores the password at all.
Authorization: role based access control (RBAC)
Once a person is authenticated, Pega looks at their Access Group. The Access Group points to one or more Access Roles, and each role is tied to classes through Access of Role to Object (ARO) records that grant rights such as Open, Update, Delete and Run report. Privileges add a finer level, for example letting only a manager reject a loan.
An Access Deny rule does the opposite of an ARO. It takes a right away for a class, and a deny always wins over a grant.
Attribute based access control (ABAC)
RBAC works at class level. When two operators share a role but should see different records, ABAC steps in. It compares a property on the record to a property on the operator, so a branch clerk only sees accounts where the branch code matches their own.
A banking example
Take a retail bank with three groups of staff:
- Tellers can open and update a Customer case, but cannot delete it.
- Branch managers get the same plus the
ApproveLoanprivilege. - Auditors can open cases and run reports but have no update right.
You would build one Access Role for each group, add ARO records for the Customer class, create the privilege, and put each role in the right Access Group. Nobody is given more access than the job needs, which is the principle of least privilege.
Hardening the platform
- Turn on rule security mode so that rules cannot be run through a URL unless they are explicitly authorised (Deny by default).
- Encrypt sensitive properties such as account numbers so they are stored as ciphertext in the database.
- Run the Security Checklist from Designer Studio before every go-live and fix anything flagged.
- Apply a Content Security Policy and keep the platform on a supported patch level.
Common mistakes
- Giving every user a broad access role "to make testing easier" and never tightening it. Grant the least access a role needs.
- Relying on role based access alone when users should only see some records. That is the job of ABAC.
- Forgetting that an Access Deny rule wins over a grant, which causes confusing "access denied" bugs that look like missing privileges.
- Leaving test or default operators enabled in a production system.
- Putting credentials inside activities or rules instead of using an Authentication Profile for outbound calls.
Security in Pega: common questions
What is the difference between authentication and authorization?
Authentication proves who the caller is. Authorization decides what that caller may do once identified. A user can be authenticated and still be denied an action.
What is the difference between RBAC and ABAC?
Role based access control grants rights on a class to a role, for example "a clerk can open and update loan cases". Attribute based access control adds a record-level test on top, for example "a clerk sees only the loans from their own branch".
What should I check before go-live?
Run the Security Checklist, review access groups and roles for excess rights, confirm test operators are disabled, and check that sensitive properties are encrypted.
Interview tip
When you are asked "What is security in Pega?", do not answer with one sentence. Walk through authentication, authorization (RBAC then ABAC), and hardening, then give a short example like the bank above. It shows you have used it on a real project.
Keep reading
For a deeper look, see our posts on every Pega security topic, including RBAC, ABAC, Access Deny and authentication profiles.
No comments:
Post a Comment