These rules take into account:
- The attributes of the client that are expressed using attributes’ expressions as defined by the language provided by the model.
- Any constraints on using roles.
*double arrows mean many-to-many relation
Two different ways to assign users to roles:
- Implicit user-role assignment: In this mode, no human intervention is allowed and RB-RBAC automatically triggers authorization rules to assign users to roles.
- A hybrid of implicit and explicit user-role assignment: Users are assigned to roles either implicitly by invoking the appropriate authorization rules, or explicitly by security administrator(s).
Seniority among authorization rules:
Satisfying an attribute pair that has high seniority level implies satisfying all the ones that have lower seniority levels.
Example 1:
We define the dominance binary relation Ð on Attribute_Expressions such that:
Ð = {( AEi, AEj) | AEi → AEj is true}
Where both AEi and AEj belong to Attribute_Expressions and “→” represents logical implication. We write (AEi, AEj) ∈ Ð which means that AEi dominates AEj.
Another way of stating the above relation between AEi and AEj is to say that Rulei is senior to Rulej (denoted by ≥):
Rulei ≥ Rulej ⇔ (AEi, AEj) ∈ Ð.
If Rulei ≥ Rulej, then this implies that users who satisfy the attribute expression of rule Rulei also satisfy Rulej and are entitled to the roles produced by Rulej.
Example 2:
One can argue that attribute expressions 2 and 3 are logically equivalent and should be consolidated in one equivalent class. In other words, one of these attributes expressions, say AE3 should be deleted. The impact of this will be discussed later.
Induced roles hierarchy
It could be argued that the most crucial step in utilizing RB-RBAC model is specifying the authorization rules.
A starting policy document is expected to list a set of flat roles the permissions of which may not be disclosed for a two-fold reason:
- Knowing the exact permissions of each role is not needed to specifying authorization rules.
- The enterprise may want to hide the details of the permissions and their level of granularity.
In order to assemble induced role hierarchy (IRH), we define dominance binary relation R on Roles such that:
R = {(ri,rj) | (∃ Rulei) (∃Rulej) [AEi → ri Λ AEj → rj Λ (AEi, AEj) ∈ Ð]}
such that (ri,rj) ∈ R means that ri is senior to rj in IRH. The IRH does not necessarily reflect the lines of responsibilities and authority as viewed by the enterprise.
In figure 4 (a) and (b), we maintain roles r2 and r3 as separate entities.
- However, the authorization rules set that produces figure 4 (a) will have 2 authorizations rules with identical attribute expressions such that one of these rules yields r2 while the other yields r3.
- On the other hand, the authorization rules set that corresponds to figure 4 (b) will have one rule that produces r2 and r3 simultaneously.
- From a functional standpoint, the two figures are identical.
- From a functional perspective, this indicates that r6 is given the permissions of r2 and r3.
- From IRH standpoint, r6 is given the user assigned to r2 and r3.
- Nonetheless, collapsing roles is not always a prudent course of action.
- When roles have different natures such as a striker and a defender in a video game. Combining these roles yields a role that is meaningless in this context.
- When the new role has so much permissions, the corresponding workload of which cannot be shouldered by a single user.
- When combining roles results in a violation of the principle of separation of duties. An example for this is the roles of programmer and tester. A user can be assigned to the programmer role. Alternatively, he may choose the tester role. If these two roles where combined, this dynamic separation will be violated.
Possible discrepancies between IRH and GRH
Two types of inheritance:
- User-role assignment inheritance, which flows from senior roles to their junior roles.
- Permission-role inheritance, which flows in the opposite direction.
Missing leaf node
Node r7 is missing in IRH, which means that no authorization rule assigns users to that role. But since the permissions of r7 are inherited by r2 and r3, both are captured in IRH, this scenario neither poses a threat to the system’s security, nor does it reduce its functionality.
To reconcile the two hierarchies, r7 is deleted from GRH and its permissions is added to its immediate ancestor(s).
If none of r7 ancestors in GRH belongs to IRH, then one of the following is true:
- The security policy, which was used to derive IRH, has overlooked parts of the business practice of the enterprise and, hence, some functionality is missing. In this case, the policy needs to be modified such that an authorization rule will assign users to the missed role.
- The business practice followed by the enterprise has created unnecessary roles to which no users are to be assigned. These roles have to be deleted from the GRH.
Missing non-leaf and non-root node
r3 is missing in the IRH part. This could result from the enterprise recognizing r3 as a semantic construct that groups several permissions, but not seeing any need for assigning users to it. From a functionality standpoint, no harm is done so long as at least one of r3 senior roles is part of IRH.
This discrepancy could be reconciled by removing r3 from GRH and assigning its permissions to its immediate senior role(s). If none of r3 ancestors in GRH belongs to IRH, then we are faced with a situation similar to the one discussed in the case above.
Missing stand-alone node
r4 in GRH represents this case. It entails harm only if the following holds:
(∀ri ∈ GRH, r4 permission set - ∪(ri permission set) ≠ φ
If the above formula holds, then some permissions of r4 can never be used. This indicates a flaw in either the security policy, or the business practice of the enterprise.
Missing root node
Assuming that node r1 in IRH is missing. This results in a loss of functionality since no user can be assigned to r1 and uses its permissions. In this case, the policy has to be modified.
Additional leaf node
Node r8 is an example of this case. To reconcile the hierarchies, r8 must be removed and the security policy must be modified such that the authorization rule(s), which produces r8, must be altered so that it does not yield this problematic role.
Alternatively, the current business practice has to be revised to incorporate r8 into GRH with the appropriate permissions.
Additional non-leaf and non-root node
r10 exists in the IRH but not in GRH.
If r10 has a single child, which belongs to GRH, then one can assume that r10 permissions set is identical to that of its child.
- However, the set of users assigned to r10 is a subset of its child’s users set.
- From a functional standpoint, r10 is redundant to its child, r5 in this case, because its users will be confined to the permissions associated with r5.
Alternatively, r10 can be added to GRH with permission set such that:
r5 permission set ⊂ r10 permission set ⊂ r2 permission set
However, if r10 has more than one child, which are nodes in GRH, then r10 can be added to GRH such that:
r10 permission set = ∪ ri permission set
where ri ∈ GRH Λ r10 ≥ ri
Additional stand-alone node
This role has no functional purpose and, thus, has to be discarded. An example for this is r9. The security policy should be modified to reflect this.
Additional root node
Assume there is a role in IRH that is senior to r1, say rroot, then we have 2 possibilities:
If r1 is the only child, then r1_permission_set = rroot_permission_set which results in functional redundancy. This can be solved by removing rroot from IRH.
If rroot has more than one child that belong to GRH, then:
rroot_permission_set = ∪ ri_permission_set
where: ri is the immediate child of rroot. GRH may be modified to adopt rroot.
Missing edges
There is an edge between r1 and r11 in GRH. However, the security policy does not recognize that and, therefore, no user-role inheritance exists between them.
The users assigned to r1 are capable of utilizing the permissions attached to r11 since they are a subset of r1 permissions even if IRH fails to reveal this hidden relation. This can be eliminated by modifying the policy so that the authorization rule that generates r1 becomes senior to the one that yields r11.
Additional edges
IRH has the edge that links r1 and r12, which GRH does not recognize.
From functional stance, this should not be a problem since it is acceptable to assign a user to roles that are not functionally related. To reconcile the two hierarchies, the permissions set of r1 need to be modified to include that of r12, which results in introducing an edge between the two roles in GRH.
Inconsistency
Part (a) of the figure suggests that since r2 is senior to r3, all users in r2 will be able to exercise the permissions of r3 in addition to those of r2. Accordingly, one can assume that r3 permissions set is included in r2.
However, part (b) shows that r2 permissions set is a subset of r3 permissions set, which indicates that any user assigned to r3 should be able to use the permissions assigned to r2. This result contradicts the one derived from part (a).
Either the policy or the role-permission assignment has to be modified.
No comments:
Post a Comment