Roles dependency hierarchy

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

For example, you can configure the access role MyApp:User as dependent on the Pega Platform™ access role PegaRULES:User4 to inherit all authorizations available in the dependent role without defining explicit Access of Role Object (ARO) records for MyApp:User. You can define this relationship by clicking Manage dependent roles. and then entering or selecting a user role in the Dependent roles field. 

The following figure shows how to start adding a dependent role to a new access role. In this example, the MyApp:User access role has no dependent roles or Rule-Access-Role-Object (R-A-R-O) rules yet. 

The following figure shows how to specify the Pega Platform rule PegaRULES:User4 is a dependent role.

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 ARO records of its own. This behavior is possible because of the following conditions:

• The absence of ARO records for the MyApp:User access role means that this access role neither grants nor denies access. The rule cannot yield any authorization outcome on its own.
• Because MyApp:User is dependent on PegaRULES:User4, any unresolved authorization checks go to PegaRULES:User4 to determine if that access role, in turn, yields an outcome.
• Because PegaRULES:User4 does not define an ARO for a case type that is specific to the MyApp application, the role-based access control (RBAC) algorithm verifies the inheritance hierarchy of that case type's class to find a relevant ARO for this check. PegaRULES:User4 does define an ARO for the Work- class (a superclass of any MyApp case types), which is the ARO that most specifically matches an instance of a case type in MyApp.
• Because the production setting value five 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. 

You can enter more than one dependent role, in which case the access roles are joined with an OR operation so that only one of the most specific AROs for each access role needs to grant access to operate.

If an access role needs 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. The system continues to defer any authorization outcomes that the top-level role does not specify to its dependent roles for an outcome.

For example, you might want to restrict MyApp users to update all case types only if they are not in the Resolved status, while preserving all other access that Pega Platform users typically get. With dependent roles, you can implement this behavior by using a single ARO in MyApp:User, which specifies the required restriction through an application-specific Access When rule. 

By leaving all other settings on the ARO unspecified, the system defers other authorization checks (for example, read access) to the dependent role (in this example, PegaRULES:User4). The dependent role continues to grant read access because no setting in the top-level role overrides this permission.

The benefits of using dependent role hierarchies include:

• Eliminating duplication of AROs for application-specific access roles: The example where MyApp needs one setting to vary an otherwise reusable baseline, when you do not use dependent roles, requires the duplication of all other settings on the ARO (and, potentially, other AROs) on the MyApp:User access role.
• Access role layering: You can create more generic access roles 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 can, in turn, depend on Pega Platform access roles), incrementally adding configuration of only the behavior that differs between the application layer and layers on which it depends.
• Multiple dependencies: You can configure access roles to have multiple dependent access roles, providing multiple dependencies to defer to so that they can achieve an authorization outcome 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 making this role dependent on multiple sibling access roles from the same application helps achieve this outcome.
• Reuse Pega Platform or your application authorization: Often the access roles in Pega Platform (or any applications on which you build) 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.
• Maintainability: By configuring only the authorization requirements that are unique to your application-specific access roles and deferring the remainder to its dependent roles, you help the maintainers of your application to understand 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 that Pega Platform provides. These slight modifications might be difficult to isolate.
• Updatability: By eliminating duplicated AROs and instead deferring to AROs for dependent roles, updates to your Pega Platform or other applications help the authorization of your applications to immediately reflect authorization changes that the update includes.

When you do not use dependent roles, your application-specific access role has no links to the new or updated access role in Pega Platform, which causes the following impact:

• The application-specific access roles mask any changes to the Pega Platform authorization model in updated access roles.
• Any new features in any Pega Infinity update might depend on privileges from the updated access roles that the application-specific access roles mask.

Check your knowledge with the following interactions: