Press "Enter" to skip to content

Access Deny & Privilege in Pega

20

Introduction

This is the continuation of Authorization topic.

Please go through ‘Access roles‘ (http://myknowpega.com/2017/05/15/67/) post first.

http://myknowpega.com/2017/05/15/67/

Access Deny

You can 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)

ADO is my own term, please forget it 🙂

As we saw before, objects refer to class instances.

So here, we deny access to particular class instances.

Privilege

  • It is a granular part to ARO or Access deny.

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

  • Say for example in an organization, we have manager and a set of developers.We need to allow executing appraisal flow only for managers and not for users.

It means that we can control executing the flow by using privilege.

You need to specify the privilege in 2 places:

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

Say, you have created a new privilege ‘ExecuteAppraisal’ and included it in Appraisal flow.

Now, this flow can be executed only by people who hold the privilege in their access roles.

Are you confused? Cool, you will be well cleared by the following examples 🙂

What is an Access Deny rule?

  • It is the reverse of Access of Role to Object.
  • Rule form is exact replica to ARO.
  • Access deny is part of security category.

How do we configure a Access Deny rule?

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.

I just copied the same from ‘ARO‘ (http://myknowpega.com/2017/05/15/67/) lesson below 😉

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

Say, you provided Level value 5. Then it will be in application till production environment.

  1. Open Instances – Controls whether you can Open FKT-Fkart-Work-Sales cases
  2. Modify instances – Controls whether you can Save FKT-Fkart-Work-Sales cases
  3. Delete instances – Controls whether you can delete FKT-Fkart-Work-Sales cases
  4. Run reports – Controls whether you can run reports of applies to class FKT-Fkart-Work-Sales
  5. Execute activities – Controls whether you can run reports of applies to class FKT-Fkart-Work-Sales
  6. Open rules – Controls whether you can open rules of applies to class FKT-Fkart-Work-Sales
  7. Modify rules – Controls whether you can modify rules of applies to class FKT-Fkart-Work-Sales
  8. Delete rules – Controls whether you can delete rules of applies to class FKT-Fkart-Work-Sales.

Let’s test it 🙂

Step 1: Create a new Access deny rule for User role – Fkart:Users

It is already created above.

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

Step 3: Open the FKart:User access role and verify the access class in the grid.

We have successfully configured to deny access to open sales case.

Step 4: Have a test user pointing to that Users access group – Fkart:Users

Note: This access group should contain the same access role – Fkart:User, where we created access deny.

Step 5: Login the User and create a new sales case.

We have created a case S-142.

Step 6: Open the case from recent/worklist.

Yes, we did it. 🙂

You can remove that access level and test again.

Keep on testing different scenarios.

What is a Privilege rule?

  • It provides access control on rules based on access role.
  • It is part of security category.

How do we configure a Privilege rule?

Step 1: Create a new Privilege rule.

Step 2: Nothing 😀

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

How do we refer a Privilege rule?

Imagine, we have a requirement like sales user can only create a sales case. Managers cannot create the case.

This is the key area in privilege rule.

You need to configure in 2 places.

1. Rules – Restricts

In the sales flow rule – Process tab

Privilege class – This will be default to Flow class.

Privilege name – Specify the privilege name here.

2. Access role – > ARO – conveys

Step 1: Open the ARO on sales class that belongs to sales user and open the Privilege tab.

Step 2: Add the Privilege created above.

Now, we have configured the sales user with the privilege to create a new case from sales flow.

For Sales manager, we didn’t add any privilege in their Access role, so they can’t create a new sales case.

Let’s jump to test.

Step 1: Make sure rules are configured with the Privilege created and Privilege is added with ARO.

Step 2: Configure the test user to ‘FKart:SalesManager’ access group – > role

Step 3: Check the manager portal, if you are able to create a new sales case.

You can’t.

Step 4: Now update the test user to sales user role – Fkart:User role.

Step 5: Now check the user portal.

You should be able to create a new case.

We have successfully configured privilege in flow rule and restricted user based on their roles.

Restricting Flow actions

Scenario: For a sales case, only sales users can change the stage. Sales manager will not have privilege to change the stage.

Note: Change stage flow action will be available through out the case life cycle in the other actions button. We shall see about those configuration in ‘Cases‘ lesson.

Step 1: First, save the flow action in application class.

Step 2: We can use the same privilege, we used for testing flow.

Configure it in security tab – Privileges.

Step 3: We  have already added the privilege in user role. Make sure it is added.

Step 4: Move to user portal and check the flow action from other actions.

Step 5: Now configure the test operator to sales manager portal and check the Actions button.

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

I wanted to show you report definition restriction, but already it’s a very long post 🙂

You can test the above rules.

Summary:

  • Access Deny is the exact opposite to ARO. Normally, we use ARO in many places.
  • Privileges need to be configured in 2 places:
  1. Rules
  2. Access role of the users

We are at the end of the post.

We will discuss how to use Access Manager in next lesson 🙂

  1. Hi,please share about activities (parameters and looping etc.)

    • Premkumar G Premkumar G

      Hi Vinod,
      Activities and Data transforms are coming in next week posts 🙂
      Please subscribe and stay tuned for more posts.

  2. madhav madhav

    it’s excelent explanation and i need to topic regarding Exception handling in pega integration

    • Premkumar G Premkumar G

      Thanks Madhav. I will take care in Integration related posts 🙂

  3. Vyas Raman Vyas Raman

    Can you describe the scenarios where only access deny is used and scenarios where only access role to object is used? To get the difference between the two rule types.

    • Premkumar G Premkumar G

      Hi Vyas,

      Access Deny gets precedence over ARO.
      Imagine a scenario – Manager access group contains three access roles – Manager, User, Approver.
      You need to restrict access to particular class.
      1. If you use ARO, then you should make sure ARO s in all three roles should be restricted to access level 0.
      2. If you use Access Deny, then you can wisely update any 1 access roles with access deny restrictions.

      Adv : Rule count is minimized and easy management.

  4. Venkatesh Venkatesh

    Nice post.. Keep up the great work.. Just want to add a point to this topic: Access deny takes precedence over access when if both returns true.

    • Premkumar G Premkumar G

      Thanks Venkatesh. Small typo in your comment. Access deny takes precedence over ARO 🙂

  5. Mathew Mathew

    I have a requirement to give permission to display a particular filed only to a particular role. I can implement this by adding visibility condition to the field to check the access role. But I want admin user to configure this permission to the roles. Is there any way we can configure and manage these type of permission using Access Manager.

    • Premkumar G Premkumar G

      Hi Mathew,
      Thanks for you comment. I don’t think controlling a particular field using access role is the right way. If you need admin to control this, have a decision table and delegate the rule to admin access group. Inside the decision table, you can administer the visibility conditions for different roles!!

  6. Vasu Vasu

    Hi Prem, Nice work!!

    Can you please share detailed explanation about Flows, flow actions and case management.

    Thanks,
    Vasu

    • Premkumar G Premkumar G

      Hi Vasu,

      Thank you so much. 🙂
      Yeah, I’ll post about them soon. Stay tuned. 🙂

      Regards,
      Premkumar G

  7. Haranadha reddy Haranadha reddy

    This is a Wonderful way of presentation. Thanks a million for your sharing of knowledge.

    • Premkumar G Premkumar G

      Thank you so much for your encouraging appreciation. 🙂
      You are most welcome, Haranadha. 🙂

  8. Srikka Srikka

    Great hard work shown by you thanks a lot PREM
    My skills are upgrading in day to day life because of highly profession presentations.

    • Premkumar G Premkumar G

      You are most welcome, Srikka. 🙂
      I’m feeling elated to read your comments. 🙂

  9. Suman Suman

    Hi Prem,
    Great work!!!
    Can this be achieved with single access group with diff level of users.
    My requirement is like have 2 levels of Sales Users.
    1st level of User should access/create sales case and 2nd level of user should not access sales case.

    • Premkumar G Premkumar G

      Yes Suman, First you need to identify which parameter differentiate level 1 and level 2. It can be within Operator page or acces group somewhere.
      Say for example, 1st level user directly reports to sales head. Then I can create a access when and provide a special privilege in the sales class ARO using access when rule. So when it return true, then they can create / modify sales case

  10. Moin Moin

    Hi Prem,
    Nice article
    Can this be achieved with single access group with level of users.
    My requirement like we have 2 levels of sales users.
    1st Level of user should access/create sales case and 2nd level of user should not access Sales case.

    • Premkumar G Premkumar G

      First you need to identify which parameter differentiate level 1 and level 2. It can be within Operator page or acces group somewhere.
      Say for example, 1st level user directly reports to sales head. Then I can create a access when and provide a special privilege in the sales class ARO using access when rule. So when it return true, then they can create / modify sales case

Leave a Reply

Your email address will not be published. Required fields are marked *

error: Content is protected !!