Access Deny, Access When and Privilege in Pega

This is the continuation of my another blog article on Authorization topic. I recommend you to visit from blog article on Access roles and ARO concepts.

In this article we will talk about Access Deny, Privilege and Access when rules.

This article was created using Pega '24 version.

First let’s start with Access Deny rules.

Access Deny

You can easily explain it with the name. Yes, we are denying the access.

Simply saying, it is the exact opposite of Access of Role to Object (ARO).

Access Deny = Access Denial of Object (ADO)

Note: ADO is my own term, please forget it 😉

We now know that Object refers to instances. We can use ARO to deny access to particular class instances.

What is an Access Deny rule?

Access Deny rule is part of the Security category and the configuration looks exactly the same as ARO.

The purpose of Access Deny is to do the exact opposite of ARO where we can configure to deny the access to objects

How do we configure an Access Deny rule?

Note: Unlike ARO, which can be created in different ways, Access Deny needs to be created manually.

Manual creation of Access Deny rules

Step 1: Create a new Access Deny rule.

Step 2: Configure the rule form.

It has a single main tab.

Security tab

If you see the right bottom corner, then you can see,

• 0 – Do not deny access.
• 5 – Access will be denied till production

Access controls – You specify the access control for various options.

In the fields, you can provide either level values (see at the right) or access when rule (Replica of when rule).

Value 0 – It means you prohibit the action completely!

1-5 represents the Production level of the systems.

Say you provided Level value 5   – Then the access control will be applicable till production environment.

Okay, now let’s look at the different controls.

Read Instances – Controls whether you can Open and read the Onboarding case instances

Write instances – Controls whether you can Create, Update and Save the Onboarding case instances

Delete instances – Controls whether you can delete the Onboarding case instances

Read rules – Controls whether you can read rules of applies to class Amazon-In-Onboarding-Work-OnboardingRequest

Write rules – Controls whether you can modify rules of applies to class Amazon-In-Onboarding-Work-OnboardingRequest

Delete rules – Controls whether you can delete rules of applies to Amazon-In-Onboarding-Work-OnboardingRequest

Execute reports – Controls whether you can run reports of applies to class Amazon-In-Onboarding-Work-OnboardingRequest

Execute activities – Controls whether you can run activities of applies to class Amazon-In-Onboarding-Work-OnboardingRequest

Let’s test Access Deny

Step 1: Create a new Access deny rule for User role – Onboarding:Managers

It is already created above.

Step 2: Configure access control for Mody instances to level value 5.

This means the Manager should be able to open the instances but not able to create, modify the instances.

Step 3: Open the Onboarding:Managers access role and verify the access class in the grid.

We have successfully configured to deny access to Create, Update or Edit the Onboarding case.

Step 4: Make sure this access role Onboarding:Managers is included in the access group and the access group to be pointed to the test Operator.

Step 5: Make sure you already have a case created. Now when you try to create or edit, you should get the error.

Note: For this blog article, I updated the built-on application to UI-Kit from Theme-Cosmos

You have the option to open in review. You can click Open in review button to open the case in review mode Case O-7

You can also remove that access deny and test again.Keep on testing different scenarios 😊

Privilege

We know that ARO, Access deny rules control the access for the class instances, whereas Privilege controls the access for particular rules.

Say for example – we have a critical report and that should be executed only by the Managers. Here we can add a privilege rule in report definition rule form and add the same privilege to the Manager access group via Access role and access role to object.

By this way we can restrict the report definition by only Manager.

You now know, we need to specify the privilege in 2 places:

1. In the rule form
2. In the Access of Role to Object -> Access role

You will understand more about privilege in the coming example 😊

What is a Privilege rule?

Privilege rule is part of the security category and it is more of a Granular security token that can control the access on individual rules.

How do we create a Privilege rule?

Privilege rule needs to be manually created.

Records -> Security -> Privilege -> Create new

Step 1: Create a new Privilege rule. DenyOnboardingRequestsReport

Note: Privilege class should be on the right object class. In our case it is Onboarding request.

Step 2: Nothing!!

There is no need to configure anything in Privilege rule form.

How do we refer a Privilege rule?

In our use case, we need to allow only managers to execute the report on Onboarding cases.

You need to refer the privilege in two places.

1. Rules – Report definition rule

Most of the rules like – Activity, flow, reports support privilege configurations.

Privilege name – Specify the privilege name here.

Save the Report definition rule.

Now, just execute the report definition rule manually from any user session.

You see no one can execute the report definition unless they have the privilege is their user profile.

2. Access role – > ARO – privilege rule.

Step 1: Open the ARO on Onboarding class that belongs to Onboarding:Managers role and switch to the Privilege tab.

Step 2: Add the Privilege created above with production level till 5.

Now, we have configured the manager with the privilege to run the report on the Onboarding request cases.

Now if you test the report execution under the managers context it will work like a charm.

You can take it as an exercise for you 😊

What are the other rules that can be restricted using privilege?

1. Activity
2. Correspondence
3. Flows
4. Flow actions
5. Report definitions
6. Attachment categories
7. Parse structured

You can test the above rules.

We can also look into two more configurations in the Access role form that are related to privileges.

Inherit privileges within the class hierarchy

In our scenario, we configured the privilege rule in ‘Amazon-In-Onboarding-Work-OnboardingRequest’ class and then updated the ARO in the same class to include the privilege.

By this way, we need to make sure, this is added at the right class layer. When you use this Option, it is not mandatory to always have the privilege added to the ARO in the same class layer.

If the ARO doesn’t exist, when this checkbox is checked then Pega looks for the class hierarchy and check for the privilege available in the parent class ARO.

Manage Dependent roles –

You get a pop-up where you can add dependent roles for the current role.

Why do we need to do it?

In our use case, we just cloned from OOTB Access role right? Actually pega recommends not to clone from OOTB instead to just mention it as Dependent role. (consider like skin inheritance or application built-on). You can just reuse all the dependent role authorization without actually clone it.

Let’s say in future releases when Pega updates the OOTB roles with new privilege may be, then we may miss that in the access roles which were clone earlier (as it is a snapshot).

Instead, you need to specify it as a dependent role so that it is always referenced and not snap-shoted!

Hope you got it 😊

Let’s talk about access when rules before ending this article.

Access when rules

Access when is the exact replica of when rules but is dedicated for Authorization or security rules.

You can just open any of the Access when rules from Records -> Security -> Access when

Click and open one of the Access when OOTB rule.

You will find the exact configuration of when rules

But then why Pega didn’t use when rules instead use access when?

– To differentiate between normal when and security when conditions.

– Also remember, only access when rules can be referred in the Access role to Object or Access Deny

In the Access control block instead of specifying values between 0-5, we can use the access when rule to conditionally grant or deny access.

All the highlighted access controls are controlled by access when rule.

Hope you got the picture of all three authorization rules from the blog article – Access Deny, Privilege and Access when rules 😊