Dealing with multiple Access Groups in Pega

Security becomes increasingly important in today´s digital world. This week a Belgian researcher proved the Wi-Fi standard WPA2 to be vulnerable to his KRACK, which allows nearby cyber criminals to listen in to over-the-air traffic.

Application security continues to be a complex topic and even modern approaches like "Security by Design" are no guarantee for (project success or) digital safety when exploits are found on some other level in the software (or hardware) stack.

At the very least, Pega platform is designed to be secure while remaining flexible enough for customers to have it fit their needs. In my experience it is crucial that all CRM project members at least have a basic conceptual understanding of the security model that is part of PRPC. This mean they should be able to differentiate Operators from Roles, but also Access Groups from Work Groups among a few other security related rule types.

What are Access Groups?

In Pega an Access Group is a per application-version rule that determines foremost:

• Available portals and which one is default after login
• Available roles (Access Role Name) which represent a pre-configure set of privileges
• Work pools which is a set of allowed work items or cases that a user can work on within an application

The role´s set of privileges is often a rather long list of classes with certain level of (or Access When) permission to read/write/delete instances and/or rules. The out-of-the-box role named "PegaRULES:Usr4" already references 59 classes. Not the speak of the per-class standard privileges you can set like AllFlows, ActionEditAttachment, DeleteAnyAttachment, clipboardViewer, etc.

Security Model Classes

Setting up security for Operators in Pega involves several interrelated classes as depicted in the following UML class diagram. Each Operator can have one or more Access Groups defined and should have at least one as default upon login. Each access group defines the level of permissions granted within a specific application.

In Pega, end-user operator usually has zero (no access) or exactly one access group per application; although the platform does not restrict you from holding multiple access groups within one and the same application. As developer you can work as Administrator as well as User and the Designer Studio menu exposes this under the Switch Application. I´ll show you the steps to enable the very same application switching in the portal as well later in this article.

Each Access Group also needs one or more Portal references which get loaded whenever an Operator gets authorized.

To control the behavior for each Access Groups one configures a list of Access Role Name rules. These role names represent a logic grouping of per class privileges. Examples of such roles are the out-of-the-box PegaRULES:SysAdm4 for "System Administrator level 4 (pega)" or PegaRULES:Usr4 for "User Level 4 (Pega) access to assignments/worklists". You can define you own application specific roles like APP:Reviewer or APP:Planner.

Security by Design

Just a few tips to keep in mind when designing an application in Pega:

• Limit the number of Access Group rules (technical) to 3 to 7 per application because of the associated administrative maintenance cost
• Limit the underlying Roles (functional) as well since their configuration size is the product of classes * privileges level of settings
• Have a separate APP:Services access group for securing the services that you expose (as API) and any Listeners and other Agents you might need
• Set Model Operators, which serve as template for LDAP authentication, to disabled to prevent abusive logins

Adding the Access Group to the Switch application menu

Any Navigation rule can be easily customized to display a description along your menu item. For the Case Worker´s navigation rule called pyCaseWorker I will leverage this property to have Pega display the Access Group as link text right under each of the Application items in the Switch application menu:

1. Open the navigation rule pyCaseWorker.
2. Click to select the Item List node named .pxApplicationLabel to open its configuration details.
3. Add property reference .pxAccessGroupLabel to the Description field.
4. Save and check-in your rule to make those changes visible in the portal.

Note: You can do the same for the pyCaseManager navigation rule.

[Edgar] (10/23/2017 9:24:52 AM)