Permission Conflicts and Collision Behavior

Policy users can be assigned to multiple roles with different data element permission settings. In this scenario, the resultant access settings applicable for that user are the least restrictive permissions derived from the data element - parent role association.

1: Inheriting Permissions for Users in Multiple Policies and Roles

Masking Rules for Users in Multiple Roles

If the mask settings, which are applied along with the permission settings, for users in multiple roles result in a conflict, then the resultant output differs.

Consider a scenario, where user U1 with a policy P1, associated with roles R1, R2, and R3 and connected with the data element DE1 containing different masks (Left, Right) and output formats, then the resultant output is applicable as per the following table.

Role	User	Data Element	Output Format	Mask Settings	Resultant Output
R1	U1	DE1	MASK	Left: 1, Right: 2	Left: 1, Right: 2
R1	U1	DE1	MASK	Left: 1, Right: 2	Left: 1, Right: 2
R2	U1	DE1	MASK	Left: 1, Right: 2	Left: 1, Right: 2
R1	U1	DE1	MASK	Left: 1, Right: 2	There is conflict in the mask settings (Left, Right) and thus, the Unprotect access is revoked with NULL as the output.
R2	U1	DE1	MASK	Left: 0, Right: 5
R1	U1	DE1	MASK	Left: 1, Right: 2 with mask character ‘*’	There is conflict in the mask character settings and thus, the Unprotect access is revoked with NULL as the output.
R2	U1	DE1	MASK	Left: 1, Right: 2 with mask character ‘/’
R1	U1	DE1	MASK	Left: 1, Right: 2	There is conflict in the mask settings (Left, Right) and thus, the Unprotect access is revoked with NULL as the output.
R2	U1	DE1	MASK	Left: 1, Right: 2
R3	U1	DE1	MASK	Left: 0, Right: 5
R1	U1	DE1	MASK	Left: 1, Right: 1 with masked mode	There is conflict in the mask settings and thus, the Unprotect access is revoked with NULL as the output. For example: If the value 12345 is masked with `Left: 1, Right: 1` settings in masked mode, then it results in 234. If the value 12345 is masked with `Left: 1, Right: 1` settings in clear mode, then it results in 1***5. As the resultant values are conflicting, the Unprotect access is revoked with NULL as the output.
R2	U1	DE1	MASK	Left: 1, Right: 1 with clear mode
R1	U1	DE1	MASK	Left: 1, Right: 2	There is conflict in the output formats. The resultant output is most permissive, which is CLEAR.
R2	U1	DE1	CLEAR
R1	U1	DE1	MASK	Left: 1, Right: 2	There is conflict in the output formats due to conflicting MASK settings. However, with the CLEAR setting applicable in the order of access as per the role R3, the resultant output is most permissive. In this case, it is CLEAR.
R2	U1	DE2	MASK	Left: 0, Right: 5
R3	U1	DE3	CLEAR

A data element-role connection with disabled permission for unprotect operation results in a NULL value, by default, and can be set to other no-access values, such as Exception or Protected value.

The following table explains how no-access values work with different output formats for users in multiple roles.

Sr. No.	Role	User	Data Element	No Access Operation	Output Format	Mask Settings	Resultant Output
1	R1	U1	DE1		MASK	Left: 1, Right: 2	There is conflict in the output formats. If one of the roles has access, then the output format is used. The resultant output is most permissive, which is MASK.
1	R2	U1	DE1	NULL
2	R1	U1	DE1		MASK	Left: 1, Right: 2
2	R2	U1	DE1	Protected
3	R1	U1	DE1		MASK	Left: 1, Right: 2
3	R2	U1	DE1	Exception
4	R1	U1	DE1		CLEAR		If one of the roles has access, then the output format is used. The resultant output is most permissive, which is CLEAR.
4	R2	U1	DE1	NULL
5	R1	U1	DE1		CLEAR
5	R2	U1	DE1	Protected
6	R1	U1	DE1		CLEAR
6	R2	U1	DE1	Exception

No Access Permissions

If the Unprotect access permission is not assigned to a user, then either the NULL value or noaccess permission, such as, Protected or Exception value is returned. The returned value is based on the permission settings for a role or a data element. If a user is assigned to multiple roles with different permission settings for the data element, then the following no-access permission on the protector is applicable.

No Access Permission 1	No Access Permission 2	Resultant Permission on the Protector
Protected	NULL	Protected
Protected	EXCEPTION	Protected
Protected	Mask	Mask
Protected	Clear	Clear
NULL	EXCEPTION	EXCEPTION
NULL	Mask	Mask
NULL	Clear	Clear
EXCEPTION	Mask	Mask
EXCEPTION	Clear	Clear

1 - Inheriting Permissions for Users in Multiple Policies and Roles

This section describes how a user in multiple policies and roles inherits permissions for a data element.

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

Policy structure in the ESA					Protector side permissions after deploying the policy
P1	R1	U1	DE1	URP	U1	DE1	URP
P1	R1	U1	DE1	URP	U1	DE2	U
P2	R2	U2	DE2	URP	U2	DE1	U
P2	R2	U2	DE2	URP	U2	DE2	URP
P3	R3	ALL USERS	DE1	U	ALL USERS	DE1	U
P3	R3	ALL USERS	DE2	U	ALL USERS	DE2	U

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

Policy structure in the ESA					Protector side permissions after deploying the policy
P1	R1	U1	DE1	URP	U1	DE1	URP
	R1	U1	DE2	-	U1	DE2	-
	R3	ALL USERS	DE1	U	U2	DE1	-
	R3	ALL USERS	DE2	U	U2	DE2	URP
P2	R2	U2	DE1	-	ALL USERS	DE1	UR
P2	R2	U2	DE2	URP		DE1	UR
P3	R4	ALL USERS	DE1	R		DE2	UR
P3	R4	ALL USERS	DE2	R		DE2	UR

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

Policy structure in the ESA					Protector side permissions after deploying the policy
Policy structure in the ESA					P1	R1	U1	DE1	URP	U1	DE1	URP
DE2	-	DE2	-			R1	U1			U1
R2	U2	DE1	-	U2		DE1	-
R2	U2	DE2	URP	U2		DE2	URP
R3	ALL USERS	DE1	U	ALL USERS		DE1	UR
R3	ALL USERS	DE2	U			DE1	UR
R4	ALL USERS	DE1	R			DE2	UR
R4	ALL USERS	DE2	R			DE2	UR

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

Policy structure in the ESA					Protector side permissions after deploying the policy
Policy structure in the ESA					P1	R1	U1	DE1	-	U1	DE1	-
DE2	-					R1	U1	DE1	-	U1
R3	ALL USERS	DE1	U	U2		DE1	U
R3	ALL USERS	DE1	U	U2		DE2	URP
P2	R2	U2	DE2	URP	ALL USERS	DE1	U
P2	R2	U2	DE2	URP	ALL USERS	DE2	-

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

Policy structure in the ESA					Protector side permissions after deploying the policy
Policy structure in the ESA					P1	R1	U1	DE1	URP	U1	DE1	URP
DE2	UP				P1	R1	U1	DE1	URP	U1
P2	R3	ALL USERS	DE2	U	ALL USERS	DE1	-
P3	R4	ALL USERS	DE2	P	ALL USERS	DE2	UP

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

Policy structure in the ESA					Protector side permissions after deploying the policy
Policy structure in the ESA					P1	R1	U1	DE1	U	U1	DE1	UP
DE2	URP				P1	R1	U1	DE1	U	U1
P2	R5	U1	DE1	P	ALL USERS	DE1	-
P3	R3	ALL USERS	DE2	URP	ALL USERS	DE2	URP

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

Policy structure in the ESA					Protector side permissions after deploying the policy
Policy structure in the ESA					P1	R1	U1	DE1	U	U1	DE1	U
DE2	-				P1	R1	U1	DE1	U	U1
P2	R1	U1	DE2	-	ALL USERS	DE1	URP
P3	R3	ALL USERS	DE1	URP	ALL USERS	DE2	-