Pega Learnings: Application Security In Pega

Application Security In Pega

Hi friends, this blog will be little bit lengthy. Application security is a Chapter in Senior System Architect Pega Course. Below are the concepts I learnt in this chapter.

If we want to login into Pega application we need some credentials that credentials is named as Operator Id in Pega

Operator ID Rule:

Below screenshot displays SSA@TGB Operator ID Rule. In security Tab we can set Password for the Operator ID.

There are different portals available in Pega.

1. Administrator - Developer will use this portal to develop or modify pega application.

2. Manager - Manager will access this portal to look at the process of works by users using report. He can also process Case allocated to him.

3. User - End User who will work on pega application.

When we create a Pega Application by default, Access group will automatically created by Pega.

What is Access Group?

Access Group is a rule where we define below major functionality

1, Which Portal should open when Operator Login.

2, List of Roles Operator has Access to.

3, Work Pool(Work Basket to which Operator ID is assigned to work).

Portal Mapping in Access Group:

Role Mapping in Access Group:

In the Above image we can see Many roles Administrator has access to and the meaning is, Admin can do administration(Rule Creation, Rule Modification, Rule Deletion, etc), He can act as Manager, He can act as User too.

Below Image is the Manager Operator ID’s Access Group.

Manager can act as Manager or he can act as User. So 2 Roles(Manager,User) added to Manager Access Roles.

Below is the User Operator ID’s Access Group.

User can act only as User. He can’t act as a manager or he can’t act as a Admin. So only one role added to User Access Group.

Work Pool Mapping In Access Group:

Here we will define the class of Works(Case) operator has access to.

ReserveIT Application’s Access Group has access to only ReserveIT Work Items. From ReserveIT Application we cant access HRApps Application.

So we have to Provide ReserveIT Work Class Group here.

Now we will see briefly about Access Roles

What is access roles?

Access roles used to categorized user according to their job functionality. Each access role defines how set of user interacts with the application to create Case.

For Example, User can create case. But Admin can only delete a case.

Note: By Default Pega will create Access Roles. If Required we can create a new role or we can modify existing role based on our requirement.

Whats Inside Access Role?

Below is the Access Role rule. Highlighted box Contain text label Clone From, it described from which Access role this access role is saved as from or from which access role this access role is overridden.

How Access Role Works?

By using access role we can define which class Operator has access to and what are all the functionality with that class rule he has access to(Read Instance, Write instance, delete instance, etc.)

Demo:

Now we are going to make HRApps:HR role has no access to EmployeeEvaluation class.

Checked out HRApps:HR role’s rule.

Before did any modification HRApps:HR role has full access to EmployeeEvaluation class.

If we click class name a popup box will open that displays Access Role of Object rule for the corresponding class there we can update access controls.

Updated all access controls to 1.

We can provide values from 0 to 5.

In Every Pega environment like Development, QA, UAT and Production there will be a Production Level.

If we provide access Control above or equals to Production Level then access is granted for the particular functionality. If we provide access Control Less than Production label then access is denied for the particular functionality.

In Our Dev Production Value is set to 4.By using the DSS(Dynamic System Settings) we can update that value. So If we provide access Control value 4 or 5 then we have access to that functionality.

If we provide Access Control as 5 then role has access till Production environment.

Now Updated all access controls to 1. So HRApps:HR Can’t able to Read instance, delete instance, Write instance, read rule, write rule, delete rule.

Logged in with HRApps:HR Credentials.

From the list of case try to Open Employee Evaluation Case.

A window shows that HRApps:HR has no access to that Case.

Updated Access Controls to 4 and checked in the changes.

Can able to open Employee Evaluation case from HRApps:HR Access roles.

Now we will see what is Access Deny rule and Privilege rule

Access Deny Rule:

Access deny rule is just opposite to Access Role of Object rule. Means We are using Access role of Object rule to grant access to classes based on Production Level . Here in Access deny rule we are denying access based on Production Level.

If We provide Access Control as 5 in Access Deny rule - Access is denied till Production environment.

If We provide Access Control as 0 or 1 in Access Deny rule - Access is Granted till Production environment.

Access Deny and Access Role of Object rule name must be same as Access Group Name.

Demo:

Create a new Access Deny rule for Candidate class.

Access Deny rule updated in Access Role.

Provided Access controls for Open,Modify,Delete instance as 5. So HRApps:HR Can’t open Candiate Instance. Lets test it by login into HR Portal.

Logged in into HRApps:HR’s Portal

From the list of case, click Candidate Case.

Access Denied. Since we set 5 as Access Control in Access Deny rule.

Lets change Access Control as 0 or Blank and test again.

Changes updated in Access Role.

Lets Open Candidate Case in HRApps:HR’s Portal.

Now can able to Open Candidate Case.

Privilege Rule:

Privilege is a granular part of Access Role of Object and Access Deny Rule.

Access Role of Object and Access Deny rule Used to control access to class. But Privilege Used to control access for Particular rule(I.e Flow, Flow Action, Property, etc.)

So If this privilege is added in any rule then that rule is accessible only if the privilege is added in the access role

Demo:

Adding Privilege in Flow Action:

We have flow in candidate case, In first Assignment(CollectCandidateDetail) we are going to add a Privilege to restrict access to available local action.

Below screenshot shows the list of local action to display in action button.

Opened pyCreateAdhosCase local action(flow action) and added Privilege in Security tab.

Created a privilege DisplayAdHocCase

In Work class added DisplayAdHocCase privilege. So this flow action will display in action button only if the DisplayAdHocCase privilege is added in Access role.

Provide production Level as 5 , so grant access.

Ran the case, in action button we can see Create Ad Hoc Case local action.

Updated Level to 0 , so the local action will not display in this access role also.

Ran the case, In Action button Create AdHoc Case local action is not available.

Adding Privilege in Flow:

Open Flow rule’s process tab.

In Security add a privilege name and its corresponding Privilege class.

HasCandidateAccess privilege created.

Candidate class in Access role before adding privilege.

Added HasCandidateAccess Privilage in TGB-HRApps-Work-Candidate class under HRApps:HR Role with production level 5.

When try to run the flow from Administrator portal system through authorization error. We added Privilege in this flow. So Access role which having this privilege can only access this flow. For other roles System will show Authorization error.

Updated production level to 0. So This role also has no access to the rule which having HasCandidateAccess flow.

Case opened but flow can’t able to open .

There are two types of Access Control:

l Attribute based access control

l Role based access control - If we want to build security based on role we can use this method(Restricting access based on roles, privilege).

Attribute based access control(ABAC):

Use attribute-based access control (ABAC) to restrict access to specific instances of classes(case, report, property), and to enforce instance-level and row-level security.

Access restrictions are enforced by defining access control policies. Conditions used in access control policies compare attributes in class instances to other information (typically, information about user’s identity, organizational reporting relationships, or other security credentials that might be case-specific).

Access is permitted only when all relevant policy conditions are satisfied.

Encryption policies under ABAC do not have associated conditions. These encryption policies are used to unconditionally encrypt sensitive property values, and can be used together with other access control policies to conditionally obfuscate or mask these values within application user interfaces.

Attribute-based access control policies do not restrict the processing of client-based access control requests.

ABAC Rules:

Access Control Policies(Rule-Access-Policy)
Access Control Policy Condition(Rule-Access-PolicyCondition)

How to use Attribute based access control?

Created a sample flow with 3 assignments. In First assignment we are getting employee details. In second assignment we are displaying provided values to manager for review and he can reject the employee case or he can approve the employee case. In 3^rd assignment we are displaying values to a user for review . He can approve or reject the case.

So In First Assignment we are getting Account Number and IFSC Code from employee . Since those details are confidential we should not allow all the user to view those data. Only Manager can view those data. For other user we should not display those data or else we can mask the Account Number and IFSC Code while displaying any screen.

Configuring Attribute based access control:

In Record Explorer -> Security Category create a new instance under Access Control Policy Rule type.

From the list of Action select PropertyRead.

Why we are selecting PropertyRead?

We are going to restrict access to particular property read by user. So we are selecting this option. We can use any action based on our requirement.

To understand about Access Control Policy Click here

Added the property to mask AccountNumber and IFSCCode. If we click the configuration icon near restriction method a pop-up box will display there we can add with which digit we can mask values and how many digit we have to mask.

Account Number we are masking with * and 10 digits we are masking.

In Access Control Policy rule, we have to add access control policy condition rule near permit access if .

If access control policy condition becomes true then user has access to view property. Or else we will mask the property.

Below screenshot shows access control policy condition rule. Here we can add logic to check.

In Condition logic I added a Access when rule(IsNotManager) If this rule becomes true then we are returning false as output to Access Control policy rule based on our condition. If the rule become false then we are returning true as output to Access Control policy rule based on our condition .

Access when rule. Here if OperatorID Unit is accounting then it will return false. Or else it will return true based on our condition.

So If We login with accounting credentials , we will mask the Account Number and IFSC or else we will grant access to view those fields.

Lets Run the case and check the rules.

First assignment screen(Admin Portal)

Case routed to next operator(Manager)

Second assignment screen(Manager Portal)

Logged in to manager portal. Case is in case manager workbasket.

Approved the case in Manager Portal

Routed to next operator(Accounting)

Third assignment screen(User Portal- Accounting work queue mapped)

Logged into Case worker portal.

Here we can see Account Number and IFSC Code is masked. Accounting user has no access.

Access Manager:

To simplify the configuration of security records, Pega provides the Access Manager. The Access Manager presents you with an easy-to-use interface for managing application security. In Dev Studio, navigate to the Configure menu and select Org & Security > Access Manager to open the Access Manager.

The Access Manager provides three tabs for configuring security settings in an application.

1. Use the Work & Process tab to configure access control for instances of a specific case type.

2. Use the Tools tab to configure access to Pega tools such as the Clipboard and Live UI for end users.

3. Use the Privileges tab to manage access to specific records, such as flow actions and correspondence records.

Work & Process Tab:

We can use this tab to update access to case for particular access group.

We can select the application to which we want to update case access.

Below is the list of Case type available in current application.

Select the access group from the list to update access to case type.

If we update the access controls from access manager it will update the changes in Access role rule.

HRApps:HR’s role candidate class before updating in Access Manager.

Updated access conrol from Access Manager wizard.

HRApps:HR’s role candidate class before updating in Access Manager.

We can update like Full Access, No Access, Conditional - we can provide some when condition to check- If that when becomes true then access granted or access denied.