Comparison of Models B 1 and B 2

The semantics of models B1 and B2 bear some resemblance, but at the same time include

some differences. In B1, a user u who receives negative authorization wrt a specific role

is not authorized to that role until:

• The authorization rules are modified, and/or • The user's attributes are changed.

In B2, when u activates a role from among a set of mutually exclusive roles, u is

prohibited from activating the rest of the roles. Effectively, this can be seen as if u has received negative authorization wrt the rest of the roles. However, if the mutual exclusion is static, u is permanently prohibited from activating these roles. This amounts to a permanent negative authorization which can not be specified using Model B1.

4.2.4 Discussion

4.2.4.1 Monotonicity

In contrast to Model A which is monotonic, the syntax of ASLB1 language permits specifying the rules such that the set of roles that a user is authorized to decreases as the number of rules he satisfies increases. Suppose that we have (┐rg) ∈ RHS(aei) and {rg ,

rh} ⊆ RHS(aej). If a user u satisfies rulej, then he is authorized to rg and rh. In case of

DTP, if u satisfies both rules, he is authorized to rh only. The above shows that Model B1

is non-monotonic. We can show that Model B2 is also non-monotonic if we modify the

case above such {rg ⊕ rh} ⊆ RHS(aei).

4.2.4.2 Other RBAC Models

In OASIS model, negative authorization of roles was suggested as a means of specifying SOD constraints. No details were given but, rather, it was referred to as a future work [BMY2002]. In addition, OASIS has the following limitations:

a. It does not distinguish between simple dynamic and session-based dynamic SOD. b. It is unable to handle static SOD, and as a result, important access control policies

like the Chinese Wall cannot be enforced.

Model B overcomes these limitations. However, it is my position that negative authorization in RBAC context is less useful than it is in a DAC environment. The limited benefit it brings may not justify the substantial amount of complexity it introduces to the model.

4.3 Summary

Model B extends the language of the base model so that the language allows specifying negative authorization and mutual exclusion. Negative authorization in the context of RBAC is a novel concept. RB-RBAC Model B1 is the first RBAC model that provides

detailed analysis of different aspects of negative authorization in an RBAC context. This includes providing semantics for the negative authorization in this new territory, identifying cases of conflict, suggesting several conflict resolution policies (many of them are novel) and analyzing the impact of negative authorization on IRH, GRH and any RB-RBAC enforcement architecture.

Model B2 provides the syntax needed to express mutual exclusion among roles in

authorization rules. Mutual exclusion is a tool to specify the time-honored Separation of Duty (SOD) constraints. Allowing mutually exclusive roles in the RHS of the authorization rules introduces conflict among rules. Different types of conflict were identified and analyzed and suitable conflict resolution polices were presented and discussed. The impact of mutual exclusion on IRH, GRH and RB-RBAC enforcement architecture is discussed. The formalization of Models B1 and B2 is provided in Figures

29 and 30.

In the following chapter, we introduce Model C which allows specifying a set of constraints that includes SODs.

Figure 29: The Formalization of Model B1

Model B1

1. The model's syntax is shown in section 4.2.1.1. 2. URAuth varies according to the policy enforced:

a. PTP: URAtuh in PTP with/without can_assume is similar to the corresponding URAtuh in Model A. b. DTP : URAuthDTP _{= A ∧ C , or}

URAuthDTP _{= {(u,r)| (∃rule}

i)[(u, aei) ∈U_AE ∧ r ∈RHS(aei)

∧ ¬ (∃rulej)[(u, aej) ∈U_AE ∧ ¬r ∈RHS(aej)]}

c. DTP with can_assume: URAuthDTP with can_assume _{= (A ∨ B) ∧ C , or}

URAuthDTP with can_assume _{= {(u,r)| ((∃rule}

i)[(u, aei) ∈U_AE ∧ r ∈RHS(aei)]

∨ (∃rulej) [(u, aej)∈ U_AE ∧ r’ ∈RHS(aej) ∧

can_assume(r’, r, t, d ) ∧ can_assume has not expired ]) ∧ ¬ (∃rulej)[(u, aej) ∈U_AE ∧ ¬r ∈RHS(aej)]}

d. LDTP: We modify the term C to require the conflicting rules to be comparable. Call the modified term C', thus URAuthLDTP _{= A ∧ C'}

URAuthLDTP _{= {(u,r)| ((∃rule}

i)[(u, aei) ∈U_AE ∧ r ∈RHS(aei)]

∧ ¬ (∃rulej)[(u, aej) ∈U_AE ∧ ¬r ∈RHS(aej)

∧ ( (aej → aei) ∨ (aei → aej)] )

e. LDTP with can_assume: URAuthLDTP with can_assume _{= (A ∨ B) ∧ C'}

URAuthLDTP with can_assume _{= {(u,r)| ((∃rule}

i)[(u, aei) ∈U_AE ∧ r ∈RHS(aei)]

∨ (∃rulej) [(u, aej)∈ U_AE ∧ r’ ∈RHS(aej) ∧

can_assume(r’, r, t, d ) ∧ can_assume has not expired ])

∧ ¬ (∃rulej)[(u, aej) ∈U_AE ∧ ¬r ∈RHS(aej) ∧ ( (aej → aei) ∨ (aei → aej)] }

f. FDTP: URAuthFDTP _{= URAuth}DTP

g. FDTP with can_assume: URAuthFDTP with can_assume _{= (A ∧ C ) ∨ B}

URAuthFDTP with can_assume _{= {(u,r)| ((∃rule}

i)[(u, aei) ∈U_AE ∧ r ∈RHS(aei)]

∧ ¬ (∃rulej)[(u, aej) ∈U_AE ∧ ¬r ∈RHS(aej) ] )

∨ (∃rulej) [(u, aej)∈ U_AE ∧ r’ ∈RHS(aej) ∧

can_assume (r’, r, t, d ) ∧ can_assume has not expired ]}

3. URAuth definition is modified to take propagation of negative authorization into account. We need to modify term C as follows:

Figure 30: The Formalization of Model B2

Model B2:

1. Syntax: See section 4.2.2.1.1 for details.

rulei: aei ⇒ {role_set1}⊕…⊕ {role_setn} such that any role-set, role_seti = {rx,..,ry} ∧ (role_seti ∩ role_setj = ∅ for any i

and j both in [1,n] such that i ≠ j)

2. ME_set(rulei) = { role_setj | role_setj is a mutually exclusive role-set in the right hand side of rulei}

3. URInvoked = {(u,r) | u has activated r at sometime in the past or is currently activating r} URInvoked = URA ∪ URD ∪ URR

4. Non-deterministic functions, Oneelement and Allother, first introduced in [CS1996]: • Oneelement (OE): set→ element.

• Allother (AO): set→set, i.e. get set by taking out one element. These two functions are related by context since for any set X,

AO(X) = X − OE(X)

and at the same time, neither is a deterministic function. Also, multiple occurrences of OE in a sentence all return the same element xi form X.

5. For Dynamic or Session Dynamic mutual exclusion: URAuth is identical to its counterpart in Model A. 6. For Static mutual exclusion:

a. URAuthStatic DTP _{= {(u,r}

g)| (∃rulei)[(u, aei) ∈U_AE ∧ (rg ∈OE(ME_set(rulei)) ∧ rh ∈OE(AO(ME_set(rulei)))) →

¬ ∃(u,rh)[(u, rh) ∈URInvoked]]} which changes according to the user's initial choice. For the sake of naming

convenience, let's call this D ∧ E.

b. URAuthStatic DTP with can_assume _{= (D ∧ E) ∨ (F ∧ G)}

{(u,rg)| ((∃rulei)[(u, aei) ∈U_AE ∧ (rg ∈OE(ME_set(rulei)) ∧ rh ∈OE(AO(ME_set(rulei)))) → ¬

∃(u,rh)[(u, rh) ∈URInvoked]])

∨ (can_assume (rk, rg, t, d ) ∧ can_assume has not expired ∧ ¬(∃rulej) [rg ∈OE(ME_set(rulej))

∧ rh ∈OE(AO(ME_set(rulej))) ∧ (u, aej) ∈U_AE ∧ (u,rh) ∈URInvoked])}, which changes

according to the user's initial choice. c. URAuthStatic FDTP _{= URAuth}Static DTP

= D ∧ E

d. URAuthStatic FDTP with can_assume _{= (D ∧ E )∨ B}

{(u,rg)| ((∃rulei)[(u, aei) ∈U_AE ∧ (rg ∈OE(ME_set(rulei)) ∧ rh ∈OE(AO(ME_set(rulei)))) → ¬

∃(u,rh)[(u, rh) ∈URInvoked]])

∨ (can_assume (rk, rg, t, d ) ∧ can_assume has not expired)}, which changes according to the