On January 11 and 12 we hosted the cLSA Security Excellence webinar as part of the CLSA Continuous Excellence Enablement (C2E) program that is focussed on targeted content on platform topics and from a Pega 8 perspective. This webinar was focussed on security and discussed authentication, authorization and security features in Pega. A number of questions was asked during the webinar that couldn't all be answered during the session. This discussion posts the questions with answers about authorization; ABAC is a separate discussion post. 

The full webinar recording can be found: https://collaborate.pega.com/discussion/clsa-security-excellence-webinar-recording-handout-january-2021

Blanks are not zero’s in RARO’s. The RARO rule form specifically states "0 or Blank = Do Not Grant Access". Is this correct for Blank?

As was explained in the Security Excellence webinar, there is a significant difference between the use of blanks and zero’s in RARO’s. A blank doesn’t do anything; it doesn’t grant or deny access. People mistakenly treat a blank as if it means a zero; zero means that you deny access.

In the past the blank and zero in RARO’s did mean the same but this was changed when the role dependencies feature was introduced in 7.3. Since than you explicitly need to use a zero when you want to deny access; using a blank can result into unexpected behavior.

Up to 8.5.2, the RARO form in the developer portal still contains a text that refers to 0 and blank both denying access. This is a bug and will be changed accordingly in 8.6.

Is the recommendation to use 'Deny' for Rule Security Mode (RSM) from the start of development of an application?

No, the Rule Security Mode Utility is available for exisiting applications that were not designed with security in mind and lack a secure setup. Applying privileges and roles can be a daunting task for large applications with many users. In order to be able to secure and harden this application without a full refactoring you can use this utility.

RSM however is not a replacement for proper RBAC and ABAC setup. RSM alone has the problem of providing or denying access to functions regardless of their context, especially when this is built off the list of allowed rules automatically from the logs.

Always start with proper authorization design using RBAC and ABAC. You can then add RSM as an additional level of security. By whitelisting individual rules, you can further narrow down what individual users can and cannot do in the system not just based on a class or context-level but down to each and every rule instance.This would also provide you with

SECU007 alert when user people try to execute other rules and this makes potential issues even easier to track down.

The use of RSM after RBAC and ABAC makes sense if the application has a high risk and exposure. For example, applications that are exposed to the internet that contain sensitive data. The downside is the high effort, especially for maintenance as you have to repeat and test the config for each change.

Can you still dynamically build up an access group based on several roles when leveraging the “Stop access checking once a relevant Acces of Role to Object instance explicitly denies or grants access” checkbox in the access group?

Yes, you can but there are things to be aware of. This setting enables you to stage the order of the Access Roles for an Access Group such that those which explicitly deny or grant access will result in a denial of access, even if later Access Roles listed for the Access Group would have granted or denied access. Watch out with Access Deny rules; the take precedence over the RARO but when an explicit grant is found earlier it will stop and not find any Access Deny that is part of a role lower in the stack.

The meaning of explicitly in the “Stop access checking…” checkbox refers to the exact class in question, so if an abstract or derived from class (like Work-) grants access, access checking will not stop with the role containing the Work- setting when the box is checked.

In the examples there are wrapper access roles for the OOTB access roles. Is this best practice?

When you use the application creation wizard it will create the wrapper roles for you. This is handy as this allows you to use the OOTB role as a dependent role and being able to override any of the RARO’s from the OOTB role in the wrapper role. This way you will always assure you have access to the latest version of the OOTB role without the need to make changes when the OOTB role has changed.

What are the options to control who performs a flow action? Especially in situations where users should be able to work on other people’s assignments on their work list.

The first thing is to assure that every flow action is secured by a privilege. This is your first line of security in preventing unwanted or unexpected access to flow actions.

When you need more dynamic ways of determining who should be able to perform the flow action, you can either work with Access When rules (like the CanPerform) or use an ABAC policy depending on the business requirements.

Looking at assignments that are in someone’s worklist; by design these are there to be performed by the worklist owner otherwise they reside in a workbasket so that multiple operators could pick it up. Normal use of the worklist should be that the worklist of users only contains the assignments they are actually working on and that shouldn’t be a huge list. After an assignment is picked up, they should be completed. If, however there is a need, then a manager could be re-assigning assignments via a manager portal. But in the end, the worklist is just a view on the open assignments, and this doesn’t provide security. Operators that hold the privilege required to perform the flow action can pick it up. Either by providing an overview of open assignments from the team or by searching for a specific work item.

Also, this community page is a good starting point for securing the application user interface https://community.pega.com/knowledgebase/articles/security/85/secure-your-application-user-interface

What is the behaviour when there are multiple dependent roles?

The dependent roles allow for a dependency hierarchy of Access Roles to be defined that allows more Persona-specific RBAC to incrementally override the role that is available from more generic Access Roles.The order of the dependent roles is significant; it evaluates the dependent roles in order until an explicit grant/deny is found. When it evaluates a role, it will continue with the dependent roles for that role before moving to the next named role in the access group.

Look at the below example:

Note that this is an app studio created access group and therefore uses the app studio managed access role (this follows the naming convention <AccessGroupName>Managed).

The App Studio Access Role is always the first Access Role evaluated by the RBAC authorization algorithm and appears on the Thread’s list of Access Roles available at runtime. This role is not part of the pyUserRoleslist but a property on its own (pyUserRoleManagedFromAppStudio).

The first role on the pyUserRoles list is in this case: Passport:User4. This role is evaluated secondly. Then it will check the dependent role for the Passport:User4 role which is in this case PegaRules:User4.

Last evaluated is the Passport:ManagementReport role.