Roles dependency hierarchy

Pega Infinity allows a dependency hierarchy of Access Roles to be defined that allows more persona (user role)specific RBAC to incrementally override the RBAC that is available from more generic Access Roles.

An Access Role MyApp:User can, for example, be configured dependent on the Pega Platform Access Role PegaRULES:User4, and ‘inherit’ all authorizations available in the dependent role without defining explicit ARO records for MyApp:User. You can define this by selecting Manage dependent roles:

Then entering Dependent roles in the Manage dependent roles dialog:

In this example, any Access Group which includes the MyApp:User Access Role, remains authorized to Read and Write instances of any Case Type despite not having any AROs (Access of Role Object(s)) 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 would not define an ARO for a Case Type specific to the MyApp application, the RBAC algorithm works its way up the inheritance hierarchy of that Case Type’s Class to try and 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 the settings of ‘5’ explicitly grant 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

Should an Access Role need to largely honour the authorization outcomes of an existing Access Role, but override the outcomes in certain scenarios, you can also use dependent roles to configure only those AROs in the new Access Role which override the outcomes that would otherwise be 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 (e.g. Read access) are deferred to the dependent role: in this example PegaRULES:User4. Read access would continue 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 would – when dependent roles are not used – require 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 utilise similar personae (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 behaviour 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 too so that an authorization outcome can be attained, based on a collection of otherwise disparate access roles. Often there are exceptional users who concurrently perform the responsibilities of multiple personae (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 you are building on) for typical personae (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 only configuring 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 would lead 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 virtue of 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 immediately reflect authorization changes that are delivered in the upgrade.

When dependent roles are not used, your application-specific Access Roles have no links to the new or updated Pega Access Roles, yielding the following impacts:

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