• No results found

Label Conflict Resolution Method

6.2 Proposed Model

6.2.2 Conflict Analysis and Resolution for the Semantic Reasoner

6.2.2.3 Label Conflict Resolution Method

Definition 16 (Conflict-free). Permission rules are conflict-free if: RP Rx + ∩

RP Ry − = ∅

Figure 6.7: Conflict caused when positively and negatively authorized rules overlap

A policy conflict is caused when their intersection is non-empty, as illustrated in Figure 6.7. Security administrators prefer to detect a conflict in advance. For con- flict cases, we introduce a conflict management system where the goal is to address conflicts between matched valid authorization rules or authorization objects. The efficiency of the model is increased if a conflict resolution mechanism is in place.

The main idea behind the label conflict resolution method is that a strategy of con- flict resolution does not inevitably ensure that all of the conflicts will be resolved. Therefore, there may remain some conflicts amidst some actual authorizations. If it can be proved that a strategy can successfully address all conflicts, then it is called an effective strategy. We propose a conflict management technique to iden- tify and resolve conflicts in a centralized manner. Our solution is based on special

Chapter 6. Role-based Administration for an Enhanced Hierarchical Model 125 labels that are basic structures useful for rule selection in conflict resolution. In SRAM, a role comprises a set of permissions that can be granted to a user. In this section, we equip each role with a special label indicating the level of a particular role (see Figure 6.8). This will assist if the role inherits the permissions from other roles; if there is a conflict, the conflict management system compares the labels of the inherited role in order to resolve the conflict. We introduce the strategy as follows.

Definition 17 (Special label). A special-label is a pair of role and level, ` =(R, L) where R is a role and L is a level.

Definition 18 (Special label ordering). Special labels are ordered according to their L component.

Security levels are assigned to roles by the security administrator. Also, the secu- rity labels (consisting of a role and a security level) are implemented by storing the nodes of the role hierarchy and specified security level locally in the semantic repository.

Strategy: The special label can effectively resolve conflicts. Let us assume that there is an actual conflict between two access control rules. An actual conflict

occurs when the Permission(act, Tper) ∩ Prohibition(act, Tper) 6= ∅. The label

conflict resolution strategy consists of the following two rules:

- `i = `j then Deny rules take precedence over allow rules;

- `i < `j then (Permission ∨ Prohibition) of `j takes precedence over `i.

The first rule states that a negative authorization prevails if the labels are on the same level. According to the second rule, the actual Permission or Prohibition of the higher label prevails. Using these rules, we cannot obtain both Permission and Prohibition at the same time. We can conclude that there is no actual conflict, which contradicts the assumption. As a consequence, the resolution method can effectively resolve the modality conflict.

The results obtained in this chapter have supported the proposed semantic rea- soner authorization model in two ways: 1) it has the ability to configure the mode of the rule such as inheritable or private rule; 2) it provides a more structured model for handling conflicting rules.

In the following, Algorithm 7 illustrates the steps to resolve policy rule conflicts. Also, using Figure 5.2, we explain a simple case of conflict between matched au- thorization objects. Table 6.1 sums up the different conflict resolution methods and the proposed method.

Chapter 6. Role-based Administration for an Enhanced Hierarchical Model 127

Example conflict scenario: Consider the ontology example in Figure 5.2 and three roles. R1 inherits permissions from two roles R2, R3. A positive permission

PRi is assigned to R2 which permits access to concepts S:Parts and HSR:Parts,

whereas R3 has PRj negative permission to the concept HSR:Parts. A conflict

management system is introduced to address conflicts between matched valid au- thorization rules or authorization objects based on the special labels assigned to every role. In this scenario, if R2 has a special label which is at the same level as

the label assigned to R3, then deny will take precedence whereby the HSR:Parts

concept is not allowed to be accessed or viewed. However, if R2 is assigned a

higher label than R3, then the rule with the higher role label will prevail and the

HSR:Parts concept can be accessed and viewed by R1.

Methods Description

Denials-take-precedence Negative authorization rule always

takes precedence

Permissions-take-precedence Positive authorization rule always

takes precedence

Prioritizing authorization The authorization that is encoun-

tered first is the one that applies

Explicit specification rule Explicit specification of the rule to

be applied

Based on a special label Use different conflict strategies

`i = `j then Deny rules take prece-

dence;

`i < `j then (Permission ∨ Prohibi-

tion) of `j takes precedence Table 6.1: An analysis of conflict resolution methods

Algorithm 7 Resolve Disjoint Conflicting Authorization

1: procedure RuleComparison(PotentialConflictSet {PR1 . . . PRk})

2: for i ←− 1 to k do

3: Rx → PR+i , Ry → PR−i+1

4: for each Ciin PR+i & Cj in PR−i+1 do

5: // Compare every Ci in PR+i with Cj in PR−i+1

6: if (Ci = Cj) then

7: Collect the conflict subpermission concept objects 8: Conflict[] = Concept objects

9: end if

10: end for

11: // Comparison of the labels to resolve conflict 12: if (`n = `m) then

13: // Deny rule takes precedence over allow rule

14: // Produce new (+) rule which does not include Conflict[] objects; 15: Produce new per rule = PR+x;

16: Result = PR+x & PR−i+1

17: else if (`n < `m) then

18: // Deny rule takes precedence over allow rule

19: // Produce new (+) rule which does not include Conflict[] objects; 20: Produce new per rule = PR+

x;

21: Result = PR+x & PR−i+1

22: else if (`n > `m) then

23: // Allow rule takes precedence over deny rule

24: // Produce new (-) rule which does not include Conflict[] objects; 25: Produce new prohi rule = PR−y;

26: Result = PR+i & PR− y

27: end if

28: end for 29: end procedure