Roles dependency hierarchy

Using dependent roles helps to standardize permissions across applications and improve the maintainability of the access control model. 

For example, you can configure the MyApp:User access role to be dependent on the PegaRULES:User4 Pega Platform access role, so that it inherits all available authorizations from a dependent role without explicitly defining Access of Role Object (ARO) records for a new role. You can define this relationship from the Dev Studio by selecting a user role in the Dependent roles field after clicking Manage dependent roles. 

The figure below illustrates how to begin adding a dependent role to a new access role. In the example, the MyApp:User access role does not yet have any dependent roles or Rule-Access-Role-Object (R-A-R-O) rules. 

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

An access group that includes the MyApp:User access role retains authorization to read and write instances of any Case Type even without any ARO records of its own. This behavior is possible due to the following conditions: 

• Because there are no ARO records for the MyApp:User access role, it neither grants nor denies access. The rule itself cannot yield any authorization outcome. 

• Because MyApp:User is dependent on PegaRULES:User4, any unresolved authorization checks are passed to PegaRULES:User4 to determine if that access role yields an outcome. 

• Because PegaRULES:User4 does not define an ARO for a case type specific to the MyApp application, the role-based access control (RBAC) algorithm checks the inheritance hierarchy of that case type's class to locate a relevant ARO for the check. PegaRULES:User4 does define an ARO for the Work- class, a superclass of all MyApp Case Types, which is the most specific ARO that matches an instance of a case type in MyApp. 

• Because the production setting value Five explicitly allows read and write access to the case type, the outcome from PegaRULES:User4 is passed on as the outcome for the same authorization check on the MyApp:User access role. 

You can enter multiple dependent roles, in which case the order is relevant (top to bottom). It stops access checking once a relevant Access of Role to Object instance explicitly denies or grants access in the dependent roles list. 

If an access role needs to mostly follow the authorization outcomes of an existing access role but override the outcomes in specific scenarios, you can use dependent roles to configure only the AROs in the new access role that override the outcomes otherwise obtained from its dependent roles. The system still defers any authorization outcomes that the top-level role does not specify to its dependent roles for a resolution. 

For instance, you may want to limit MyApp users to updating all case types, except those in the Resolved status, while retaining all other access the Pega Platform users typically get.  

You can implement this behavior using a single ARO in MyApp:User with dependent roles, which applies the necessary restriction through an application-specific Access When rule. 

By leaving all other settings on the ARO unspecified, the system defers other authorization checks, such as read access, to the dependent role (in this case, PegaRULES:User4). The dependent role still grants 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: In the scenario where MyApp requires one setting to differ from an otherwise reusable baseline, not using dependent roles necessitates duplicating all other settings on the ARO (and possibly other AROs) on the MyApp:User access role. 

• Access role layering: You can create more generic access roles to serve as the authorization foundation for application-specific access roles that share similar user roles. Application-specific access roles can then depend on the more generic access roles (which can, in turn, depend on Pega Platform access roles), gradually adding configuration for only the behavior that varies between the application layer and the layers on which it depends. 

• Multiple dependencies: You can configure access roles to have multiple dependent access roles, offering several dependencies to defer to so that they can attain an authorization outcome based on a combination of otherwise distinct access roles. Sometimes, certain exceptional users perform the responsibilities of multiple user roles simultaneously. Creating an access role for these users and making it dependent on multiple sibling access roles from the same application helps achieve this outcome. 

• Reuse Pega Platform or your application authorization: In Pega Platform applications, the access roles for typical user roles such as end users, managers, and system administrators often cover most of the necessary authorization outcomes. Implementing application-specific access roles that depend on the corresponding Pega Platform access roles establishes a functional authorization baseline without duplicating AROs. 

• Maintainability: By configuring only the authorization requirements that are specific to your application-specific access roles and deferring the rest to its dependent roles, you assist the maintainers of your application in comprehending how your application-specific authorization differs from a more universally comprehended foundation. Configuring RBAC without dependent roles results in a greater number of AROs at the application level, many of which are frequently slightly modified clones of the access roles that Pega Platform offers. These minor variations may be challenging to identify. 

• Updatability: Eliminating duplicated AROs and instead deferring to AROs for dependent roles ensures that updates to your Pega Platform or other applications immediately reflect authorization changes that the update includes. 

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

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

Check your knowledge with the following interactions: