Pega Attribute Based Access Control

Security in general is associated with two basic terminologies – Authentication & Authorization

Authentication

Authentication is the process of verifying user’s identity against any database or external systems like LDAP, SAML etc.

Example: In order to place an order, consumers must input their user name and password into the Amazon app. In this scenario, authentication refers to the process that determines access once the user name and password are input and validated against Amazon’s user database.

Authorization

Authorization is the process of verifying what actions can an authenticated user perform in the system.

Example: Amazon has introduced exclusive offers and discounts on specific products that are exclusively available to Prime customers. Authorization in this context refers to the process of verifying the logged-in user’s membership type and then deciding whether or not the deals or discounts need to be displayed.

Authorization models provided by Pega are:

In this post, we will see in detail about Attribute Based Access Control (ABAC).

What is Attribute based access control?

This authorization model, as its name implies, compares user attributes with object attributes to determine the access. The policy engine evaluates policies against user and object attributes & determines to permit or deny access to users. ABAC is not a replacement for RBAC. It complements RBAC and offers more granular security control.

Pre-requisites

To enable ABAC in the application,

• The user needs to have the privilege pzCanManageSecurityPolicies
• Dynamic system setting “EnableAttributeBasedSecurity” should be set to true

Rules associated with ABAC

• Access Control Policy (Specifies actions and conditions for which the policy is applicable)
• Access Control Policy Condition (Defines a set of policy conditions that evaluates user property values or other information on the clipboard)

When we talk about the business scenario later in this post, we will take a closer look at how these rules are configured and used.

Scope of ABAC

ABAC can be used to implement authorization models for the below set of actions,

• Update – Create or update a case or data
• Read – Open the case or view data for the case in reports, searches etc.
• Discover– View limited information about a case that doesn’t meet Read conditions but satisfies Discover conditions
• Delete– Delete a case or data
• Property Read – Restrict visibility of property values
• Property Encrypt– Property is encrypted in DB, clipboard, logs, searches etc.

Business Scenario

Consider a loan application with the following steps and security requirements:

• Client reaches to a loan officer for getting their loans sanctioned. Loan officer gathers client’s basic information, contact information, loan details and verifies the document and then initiates loan request. Only loan officer can enter all these details and submit the loan for further processing.
• Once the loan request is submitted, manager reviews the case and can either approve or reject or request for more information. The approval step can be performed only by the managers. When manager requests for more information, the case goes back to loan officer’s work queue.
• Only the loan officer who initiated the case and the managers can view all the details of the case.
• During approval, manager can categorize the application as Premium, Special or Regular. The loan processing types can be deleted only by managers. Manager also enters the loan limit while approving.
• Loan officers who created the case and managers should have an access to report that displays all the loan requests that are approved and resolved. Loan limit should be masked for loan officers. Only managers should be able to see the loan limit.

Case Design

A case type LoanProcessing is created for the above requirement with 3 stages- Initiate Loan Process, Approval and Resolve. In Initiate Loan Process, Loan Officer enters the details provided by client and verifies the documents. Status is set as Pending. In Approval stage, the case status is set as Pending-Approval. Manager can Approve, Reject or Move the case back to Loan Officer’s work queue. If case is approved or rejected the case is resolved as Resolved-Completed or Resolved-Rejected.

Let us now see how security requirements can be accomplished using ABAC authorization model.

Security Requirement #1 – Only loan officer can enter details and submit the loan request for further processing.

Let us begin by creating an access when rule to check if the logged in user is a LoanOfficer. This is done by checking the access group of the logged in user as shown below.

Next, we can create an access control policy condition that allows only Loan Officer to enter details of the loan. From the case design, we know that the status of the case while the details are being filled is Pending. We can configure access control policy condition that evaluates to true only for Loan Officers (by using IsLoanOfficer access when) when the case status is Pending. For other users, we are allowing access when case status is XXX which is never going to be a possible scenario as per the case design, thus, restricting the access to update the details or submit the case.

The next step is to configure an Access Control Policy with Update access in the context of case type class. After creating this rule, we will be adding the above access control policy condition.

Let us try to create a case using admin operator. The access group of the admin operator is LoanReq:Admin. We can see that this user is restricted access to create a loan request.

We will now use LoanOfficer operator ID to create case and move forward to approval stage.

Security Requirement #2 – The approval step can be performed only by the managers.

To achieve this, we can create an access when rule to check if the logged in user is a manager. We can then update the same access control policy condition that was created, to allow access to manager when case status is Pending-Approval. No change is needed to access control policy rule.

Let us try to use admin operator to update the case in Approval stage. We can see that the user is restricted access.

Security Requirement #3 – Only the loan officer who initiated the case and managers can view all the details of the case.

To achieve this, we need to create an access control policy condition that checks if the Loan Officer is the case creator or if the user is manager to permit access. An access control policy with Read action refers to this access control policy condition.

Security Requirement #4 – The loan processing types can be deleted only by managers.

To achieve this, an access control policy condition is created in the data class of loan processing types to provide access to managers and not to provide access to any other type of users. This access control policy condition is then applied inside access control policy of action Delete.

Security Requirement #5 – Loan limit should be masked for loan officers. Only managers should be able to see the loan limit.

To achieve this, an access control policy condition is created which evaluates to true only for Managers.

Access Control Policy with Action as Property Read should be created and refer to the above access control policy condition. In the list of properties, select property as Loan Limit and configure the masking. Since, this is a decimal value, masking format can be a number only. In this scenario, we have used 0 as masking character. For string properties any character like * or – etc. can be used for masking.

On running the report using Loan Officer login, the value of loan limit is masked, while, managers can view the actual value.

Important characteristics of ABAC

1. Access Control policies can be defined only for the instances of Assign-, Data- and Work-.
2. Pega class based inheritance is applicable to ABAC.
3. When multiple policies are defined for a specific class or if multiple policies are inherited by a specific class, all the conditions specified in all the policies must be met for providing a grant, i.e. all the conditions from all policies are combined using AND.
4. ABAC enforcement is applicable to report rules, operations on individual case instances like Open a case, Update a case, Delete a case etc., Search operations and Custom SQL.
5. If overriding of access control policy in the descendent class with same name has to be prevented, then there is an option to select Disallow creation of a policy with the same name as a descendant class.
6. Access Control Policy Condition is added to the access control policy rule form to allow or restrict access except for Property Encrypt type.
7. Search Queries will not be impacted by ABAC written on Data- classes.
8. Custom SQL is impacted only by Read policy.

Stay tuned for more posts on Security!!!