Inheriting Permissions for Users in Multiple Policies and Roles

If 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 the 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.

Example:

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 Working with 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 that is they are part of different policies but they are deployed to the same data store, they have inherited the permission of the default role for data elements DE1 and DE2.

Table 1. Use Case 1

As shown in the table, in the case of old behaviour, no permissions have been inherited from the role R3 that is applicable to the data elements DE1 and DE2 for all the users.

The Unprotect permissions highlighted in bold in the table for the new behavior column indicate the permission, that have been inherited from the role R3, that 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. In this case, protector side permissions after deploying the policy are the same as shown in the old behavior and new behaviour columns.

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. In this case, protector side permissions after deploying the policy are same as shown in the old behavior and new behaviour columns.

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

As shown in the table, in the case of old behaviour, no permissions have been inherited from the role R3 that is applicable to the data element DE1 for all the users.

The Unprotect permission highlighted in bold in the table for the new behavior column indicate the permissions that has been inherited from the role R3, that 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

As shown in the table, in the case of old behaviour, no permissions have been inherited from the roles R3 and R4 that is applicable to the data element DE2 for all the users.

The resultant permissions highlighted in bold in the table for the new behavior column indicate the permissions that have been inherited from the roles R3 and R4, that is 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

As shown in the table, in the case of old behaviour, no permissions have been inherited from the role R3 that is applicable to the data element DE2 for all the users.

The resultant permissions highlighted in bold in the table for new behavior column indicate the permissions that have been inherited from the role R3 that is applicable to the data element DE2 for all the users.

Use Case 7

The Use Case 7 table demonstrates that if role R1 is related to data element DE1 in policy P1 and and role R3 is related to data element DE1 in policy P3, then roles R1 and R3 will not inherit the permissions of the default role. In this case, protector side permissions after deploying the policy are same as shown in the old behavior and new behaviour columns.

Table 7. Use Case 7

• ←Previous
• Next→