Inheriting Permissions

A special case exists when a user is present in multiple roles, this creates a conflict. This section provides information about how the software resolves this conflict. As a general rule, the software applies the most restrictive permissions.

Typically, when a policy user is assigned a role that does not have a specific data element associated with the role, then the user cannot use the data element for performing security operations. If the user tries to use the data element, then an error is generated.

However, consider a policy where you have created a default role that is applicable to all users. You associate a specific data element with this default role. In this case, the policy user, who is included in another role that is not associated with the specific data element, inherits the permissions for this data element from the default role. This scenario is applicable only if the users are a part of the same policy or a part of multiple policies that are applied to the same data store.

When a user is part of multiple roles or policies, the system must resolve potential permission conflicts. The Search Member Access tab in the Roles & Member Sources section allows you to view the effective permissions a user has on data elements. This includes permissions inherited from multiple roles and policies.
For more information about effective permissions, refer to Searching Member Access.

Scenario:

Policy 1 contains the role R1, which is assigned to the user U1. The role R1 is associated with a data element DE1, which has the permissions Unprotect, Protect, and Reprotect. The user U1 can unprotect, protect, and reprotect the data using the data element DE1.

Policy 2 contains the role R2, which is assigned to the user U2. The role R2 is associated with a data element DE2. which has the permissions Unprotect, Protect, and Reprotect. The user U2 can unprotect, protect, and reprotect the data using the data element DE2.

Policy P3 contains the role R3, which is applicable to all the users. The role R3 role is associated with two data elements DE1 and DE2. Both the data elements have the Unprotect permissions associated with it.

Note: The ALL USERS denotes a default role which is applicable to all the users. To enable the default role, click the Applicable to all the members toggle button on the ESA web UI. For more information about Applicable to all the members, refer to the section Roles.

Use Case 1

The Use Case 1 table demonstrates that roles R1 and R2 have an indirect relationship with data elements DE1 and DE2. The roles are part of different policies that are deployed to the same data store. As a result, the roles R1 and R2 have inherited the permission of the default role for data elements DE1 and DE2.

Table 1. Use Case 1

The Unprotect permission is highlighted in bold in the Protector side permissions after deploying the policy column. This Unprotect permission indicates that it has been inherited from the role R3, which is applicable to the data elements DE1 and DE2 for all the users.

Use Case 2

The Use Case 2 table demonstrates that if roles R1 and R2 have a direct relationship with data elements DE1 and DE2, then they will not inherit the permissions of the default role.

Table 2. Use Case 2

Use Case 3

The Use Case 3 table demonstrates that if roles R1 and R2 have a direct relationship with data elements DE1 and DE2, then they will not inherit the permissions of the default role.

Table 3. Use Case 3

Use Case 4

The Use Case 4 table demonstrates that as role R2 has an indirect relationship with data element DE1, it has inherited the permissions of the default role. The role R1 has a direct relationship with data element DE1, and it have not inherited the permissions of the default role.

Table 4. Use Case 4

The Unprotect permission is highlighted in bold in the Protector side permissions after deploying the policy column. This Unprotect permission indicates that it has been inherited from the role R3, which is applicable to the data element DE1 for all the users.

Use Case 5

The Use Case 5 table demonstrates that Role R1 has inherited the permissions of the default role for the data element DE2.

Table 5. Use Case 5

The resultant permissions are highlighted in bold in the Protector side permissions after deploying the policy column. These permissions indicate that they have been inherited from the roles R3 and R4, which are applicable to the data element DE2 for all the users.

Use Case 6

The Use Case 6 table demonstrates that role R1 will inherit the permissions of the default role for the data element DE2.

Table 6. Use Case 6

The resultant permissions are highlighted in bold in the Protector side permissions after deploying the policy column. These permissions indicate the permissions that have been inherited from the role R3, which is applicable to the data element DE2 for all the users.

Use Case 7

In Use Case 7 table, role R1 is related to data element DE1 in policy P1 and and role R3 is related to data element DE1 in policy P3. In this case, roles R1 and R3 will not inherit the permissions of the default role.

Table 7. Use Case 7