Attribute based access control in Pega (ABAC)

Pega ABAC vs RBAC

As we all know, securing our application and data is very important in real-time. We can provide security to our application and data by defining some policies, conditions, and controlling app features and user actions.

Pega defines some access control rules to define and secure our application.

Access roles, Access Role to object, Access deny, Privilege these are all to grant or deny access to an application to the user. Pega has two mechanisms ABAC and RBAC.

Role-based access control vs Attribute-based access control in pega

RBAC: Role-based access control

We use RBAC to control the user's role to access some UI elements or to perform only some actions on the UI elements. UI elements mean sections harness flow actions.

For example, An assignment has 3 flow actions and we want to restrict one flow action to one or certain users, we use privileges in the security tab of the flow action rule.

We will configure RBAC by defining authorization and privilege rules.

RBAC uses three main rules:

1. Access Roles (Rule- Access-Rolename)
2. Access Role to object(Rule-Access-Role-Object) (ARO)
3. Access Deny rules(Rule-Access-Deny-Obj)

Role + Class = ARO/Access Deny

RBAC enforces security based on user roles defined in the access group.

Attribute-based access control in pega

To restrict specific instances of a particular class or property to users we can use ABAC.

For example: In my application want to restrict SSN number to a particular user. This means I don't want to display my SSN number value to a particular user or set of users (groups).

ABAC rules:

1. Access Control Policies (Rule-Access-Policy)
2. Access Control Policy Conditions (Rule-Access-PolicyCondition)

ABAC enforces explicit security through access control policies and conditions.

Pega defined some characteristics of ABAC access control policies:

1.Class limitations

We can define access control policies only for certain classes in the pega rules database.

Assign-, Data- and Work-

2.Inheritance

Access control policies use Pega inheritance functionality.

3. AND conditions

We can combine multiple access policies to grant access. If we have both ABAC and RBAC is defined and combined, when ABAC policy grants access, RBAC must also grant access.

4.Control enforcement

We can use access control policies to enforce not only UI elements but other areas.

    a. All Reporting rules (list view, summary view, and report definition

            If we want to show/hide one property in the report to a particular user, we can do that.

  b. Search - we can restrict users not to search for a particular instance.

  c. Custom SQL written statements. 

How to configure ABAC in Pega?

To setup ABAC in the application, we need to determine three things.

1. Identify Attributes (ex: Properties)

2. Define Access Control Policy Conditions Condition (Rule-Access-PolicyCondition)

3. Define Access Control Policy (Rule-Access-Policy)

Attribute-based access control examples

 I want to restrict sensitive information to particular users. In my Assistance Request application for car services the user will enter SSN (Social Security Number- XXX-XX-XXXX) and pega will format that to XXX-XX-XXXX. I want to restrict (mask) this information to other user groups except for the Billing department. If the user belongs to the billing department then SSN will be shown fully otherwise pega will mask the SSN field.

Attribute-based access control implementation.

1. Attributes - We have identified the SSN attribute.

2. Define access control policy conditions.

  From the Create menu, select Security > Access Control Policy Condition to open the Create Access Control Policy Condition form.

First, we need to create Access When rule "IsBilling" then we use this access when in PolicyCondiiton rule and PolicyCondition rule in AccessPolicy rule.

Access When rule:

Access Policy Condition rule:

Create Access Policy Condition rule to define the conditions under which to avoid masking the SSN field. If the Operator ID is related to billing we are not masking the SSN field and when the first user enters the SSN value we are not masking. In all other situations will mask the SSN field.

First, the Access When rule(IsBilling) will be evaluated if it is true then Policy Condition (A) will be applied. If Access When (IsBilling) returns false then Policy Condition (B) will be applied.

3. Access Control Policy:

Create Access Control Policy rule and refer Policy Condition rule and select masking settings for SSN property.

• • Read – The user can open a case that meets the policy conditions or view data for the case in lists, reports, searches, and so on.
  • Update – The user can create a case that meets the policy conditions or update data for such a case.
  • Discover – The user can see limited information (defined by a developer) about a case that does not meet Read policy conditions, but does satisfy the Discover policy conditions.
  • Delete – The user can delete a case that meets the policy conditions.
  • PropertyRead – The user has restricted visibility to property values, including property values with reading and update access.
        .  PropertyEncrypt – The property is encrypted in the database, clipboard, logs, and search indexes.

From the above screen, we can see three options to mask SSN. Full, first N, or Lat N characters/letters. Let's Create a case and test it.

The user enters SSN and submits the case till the Service stage. In-Service stage case is routed to the manager who is having a different access group (GoGoRoad: Managers). When the manager opens the case from his work list SSN should be masked.

Log in with the manager and open the case from the work list and see the ssn field.

Once Manager submits the case main case will be resolved and a new child case (billing) will be created and routed to the Billing department. If we open the case from the Billing user worklist SSN value should be visible.