Roles dependency hierarchy

Pega Platform™ allows you to define a dependency hierarchy of access roles that allow you to customize access control for use cases that require specific permissions while otherwise retaining permissions inherited from a standard access role. The concept behind a role dependency is that instead of a client “cloning” a role and then customizing it; the client creates a new role which is based on – dependent on – a Pega role which is shipped with the product. The client’s new role will not only have the privileges provided by their customized role, but will also inherit the privileges provided by the dependent role.

The use of dependent roles helps to standardize permissions across applications and improves the maintainability of the access control model.

An access role MyApp:User can, for example, be configured as dependent on the Pega Platform™ access role PegaRULES:User4, and inherit all authorizations available in the dependent role without defining explicit Access of Role Object (ARO) records for MyApp:User. You can define this by clicking Manage dependent roles.

In the Manage dependent roles dialog box, in the Dependent roles field, enter or select a user role.

In this example, any access group that includes the MyApp:User access role remains authorized to read and write instances of any case type despite not having any Access Role to Object (ARO) records of its own. This is because:

• The absence of ARO records on the MyApp:User access role means that this access role neither grants nor denies access. It yields no authorization outcome on its own.
• As MyApp:User is dependent on PegaRULES:User4, any unresolved authorization checks are deferred to PegaRULES:User4 to determine if that access role, in turn, yields an outcome.
• As PegaRULES:User4 do not define an ARO for a case type specific to the MyApp application, the role-based access control (RBAC) algorithm works its way up the inheritance hierarchy of that case type's class to find a relevant ARO for this check. PegaRULES:User4 does define an ARO for Work- (a superclass of any MyApp Case Type), which is the ARO that most specifically matches an instance of a Case Type in MyApp.
• As setting 5 explicitly grants read and write access to the case type, this outcome from PegaRULES:User4 is propagated as the outcome for the same authorization check on the MyApp:User access role.

The user has the option to enter more than one dependent role. If so, the access roles are joined with an OR operation such that only one of the most specific AROs for each access role needs to grant access to operate.

Should an access role need to largely honor the authorization outcomes of an existing access role but override the outcomes in certain scenarios, you can also use the dependent roles to configure only those AROs in the new access role, which overrides the outcomes that are otherwise attained from its dependent roles. Any authorization outcomes not specified in the top-level role continue to be deferred to its dependent roles for an outcome.

For example, consider a requirement to restrict MyApp users to update all case types only if they are not Resolved, whilst preserving all other access typically afforded to Pega Platform users. With dependent roles, this can be implemented using a single ARO in MyApp:User, which specifies the required restriction (using an Application-specific Access When rule):

By leaving all other settings on the ARO unspecified, other authorization checks (for example, read access) are deferred to the dependent role (in this example, PegaRULES:User4). Read access continues to be granted by the dependent role, as no setting in the top-level role overrides it.

The benefits of using Dependent Role hierarchies are:

1. Eliminating duplication of AROs for application-specific access roles: The example above where MyApp needed one setting to vary an otherwise reusable baseline — when dependent roles are not used — requires all other settings on the ARO (and potentially other AROs) to be duplicated into the MyApp:User access role.
2. Access role layering: More generic access roles can be created to form the authorization foundation for application-specific access roles that use similar user roles. Application-specific access roles can then establish a dependency on more generic access roles (which may, in turn, depend on Pega Platform access roles), incrementally adding configuration of only that behavior, which differs between the Application layer and layers on which it depends.
3. Multiple dependencies: Access roles can be configured to have multiple dependent access roles, providing multiple dependencies to defer to so that an authorization outcome can be attained based on a collection of otherwise disparate access roles. Often some exceptional users concurrently perform the responsibilities of multiple user roles. Creating an access role for these users and having it depend on multiple sibling access roles from the same application may achieve this outcome.
4. Reuse Pega Platform or Pega application authorization: Often, the access roles resident in Pega Platform (or any Pega applications on which you are building) for typical user roles such as end users, managers, and system administrators yield most of the required authorization outcomes. Implementing application-specific access roles to depend on the corresponding Pega Platform access roles provides a working authorization baseline with no duplication of AROs.
5. Maintainability: By configuring only the authorization requirements that are unique to your application-specific access roles and deferring the remainder to its dependent roles, it is clearer to maintainers of your application how your application-specific authorization deviates from a more commonly understood foundation. Configuring RBAC without dependent roles leads to a larger number of AROs at the application level, many of which are often slightly modified clones of the access roles provided by Pega. The slight modifications can be hard to isolate.
6. Upgrade-ability: By eliminating duplicated AROs and instead deferring to AROs specified in dependent roles, upgrades to your Pega Platform or Pega applications better allows the authorization of your applications to reflect authorization changes that are delivered in the upgrade immediately.

When dependent roles are not used, your application-specific access role has no links to the new or updated Pega access role, yielding the following impacts:

• The application-specific access roles mask any changes to the Pega’s authorization model in upgraded access roles.
• Any new features delivered in any Pega upgrade may depend on Privileges from the upgraded access roles that the application-specific access roles mask.