SACMAT 03© Mohammad Al-Kahtani1 Induced Role Hierarchies with Attribute-Based RBAC Mohammad A. Al-Kahtani Ravi Sandhu George Mason University NSD Security,

SACMAT 03 © Mohammad Al-Kahtani 1

Induced Role Hierarchies with Attribute-Based RBAC

Mohammad A. Al-Kahtani Ravi Sandhu George Mason University NSD Security, Inc. &

[email protected] George Mason University [email protected]


Introduction

• Role-Based Access Control (RBAC): A proven alternative to DAC and MAC

• RBAC basic components:1. Users2. Roles3. Permissions

RoleHierarchy

Users

(UA) User

Assignment

(PA) Permission Assignment

RolesPermiss-

ions


Introduction

• In RBAC, user-to-role assignment is done manually.

• Many enterprises have huge customer bases: Banks Utilities companies Popular web sites

In this environment, manual assignment becomes a formidable task.

• RBAC is modified to allow automatic user-role assignment based on authorization rules.


Introduction

• The modified RBAC is called RB-RBAC: Rule-Based RBAC.

• Authorization rule structure:

• RB-RBAC rules are in BNF notation.

Constraints

AttributesExpression

Roles


RB-RBAC Model

• Attributes Expressions:

1. Expressed in RB-RBAClanguage

2. Constitute LHS of authorization rules

• Attributes Values:1. Stored locally2. Provided by attribute

servers3. Other means

AttributesExpressions

Users

Roles

PermissionsAttributes

values


Analysis of RB-RBAC

Seniority Relations among authorization rules

• Rule i:

• Rule j:

aei aej Rulei Rulej

AttributesExpression aei

Roles

Roles

Logically implies

AttributesExpression aej


Analysis of RB-RBAC

Example:Attribute Expressions Roles Seniority

ae1 = Salary > 1000 Λ age > 50 r1 ae1 → ae2,

ae1 → ae3,

ae1 → ae4

ae2 = Salary > 1000 Λ age > 40 r2 ae2 → ae4

ae2 ae3

ae3 = ┐( Salary ≤ 1000 V age ≤ 40) r3 ae3 → ae4

ae3 ae2

ae4 = Salary > 400 r4

ae5 = Age > 60 r5 Not related to any attribute expression


Analysis of RB-RBAC

Example: (Continued)

• The seniority relations among the rules is reflected as a hierarchy among the attribute expressions of the rules.

• These relations induced a role hierarchy (IRH) among the roles produced by these rules.

ae1

ae3ae2

ae4

ae5


Analysis of RB-RBAC


To assemble the IRH, we say ri is senior to rj if the following holds:

(aeg) [ri RHS(aeg) (aeh) [(aegaeh) Λ rjRHS(aeh)]]

where RHS(aeg) is a function that returns the role set produced byattribute expression aeg.

r1

r3r2

r4

r5


Analysis of RB-RBAC


• In assembling the IRH, roles produced by equivalent attributesexpressions may be:

a. Grouped under one rule (Figure a): No impact on functionality.b. Consolidated into one role (Figure b): May not always be

preferred from a functional perspective.

r1

r2 ,r3

r4

r5

(a)

r1

r6

r4

r5

(b)


Analysis of RB-RBAC

Given Role Hierarchy (GRH) vs. IRH

• GRH reflects the current business practice of an enterprise.• Inheritance of permissions flows upward in the GRH.• Users’ inheritance flows downward in the IRH.

r1

r6

r9

IRH

r2

r10

Flow of user-role inheritance:r2 inherits r1

r8

r5

r11r12

r13 r1

r3

r6

r4r2

r7

GRH

Flow of permission-role inheritance:r1 inherits r2

r5

r11

r12

r13


Analysis of RB-RBAC

Discrepancies between IRH and GRH

• Ideally, IRH and GRH should be mirror images of each other.• In reality, discrepancies may occur.

• Types of discrepancies (using IRH as the reference):1. Missing Nodes2. Additional Nodes3. Missing Edges4. Additional Edges5. Inconsistency


Analysis of RB-RBAC


1. Missing Nodesa. Leaf Node: r7

Functional Impact: None Reconciliation Measure: Delete the node and assign its

permissions to its parents in GRH .


Analysis of RB-RBAC


1. Missing Nodesa. Leaf Nodeb. Internal Node: r3

Functional Impact: None Reconciliation Measure : Delete the node from GRH and assign

its permissions to its parents


Analysis of RB-RBAC


1. Missing Nodesa. Leaf Nodeb. Internal Nodec. Stand-alone Node: r4

Functional Impact: Loss of functionality may occur. Reconciliation Measure: Modify the authorization rules via

modifying the security policy.


Analysis of RB-RBAC


1. Missing Nodesa. Leaf Nodeb. Internal Nodec. Stand-alone Noded. Root Node: (assume r1 is missing in IRH) r1

Functional Impact: Loss of r1 functionality. Reconciliation: Modify the authorization rules via modifying

the security policy.


Analysis of RB-RBAC


2. Additional Nodesa. Leaf Node: r8

Functional Impact: None Reconciliation: Delete the node from IRH or modify GRH by

adding r8. IRH provides an insight:

r8 permissions its parent’s permission


Analysis of RB-RBAC


2. Additional Nodesa. Leaf Nodeb. Internal Node: r10

Functional Impact: If r10 has one child, then it is redundant. Reconciliation Measure: Delete r10 from IRH and modify the

policy to produce its child e.g. r5 Or add r10 to GRH such that:

r5 permission r10 permission r2 permission

If r10 has more than one child, then add to GRH with: r10 permissions = its children’s permissions


Analysis of RB-RBAC


2. Additional Nodesa. Leaf Nodeb. Internal Nodec. Stand-alone Node: r9

Functional Impact: None Reconciliation: Delete the node and modify the security policy

so that authorization rules do not produce this role.


Analysis of RB-RBAC


2. Additional Nodesa. Leaf Nodeb. Internal Node:c. Stand-alone Noded. Root Node: r13

Functional Impact: If r13 has a single child, r13 is redundant. Reconciliation: Delete r13 from IRH, and the policy must be

modified to produced its child instead.

If r13 has more than one child, then add it to GRH: r13 permission = r13 child nodes permissions


Analysis of RB-RBAC


3. Missing Edges: r1- r11

Functional Impact: None Reconciliation: The enterprise business practice sees a functional relation between r1 and r11.

However, the security policy does not capture this so it mustbe modified.


Analysis of RB-RBAC


4. Additional Edges: r1- r12

Functional Impact: None Reconciliation: Modify the permissions of r1 to include that

of r12 if the two hierarchies must be compatible.


Analysis of RB-RBAC


5. Inconsistency: Normally, user-role assignment inheritance and permission-role

inheritance flow in opposite directions. Figure (a):

(r2 r3) r2 users have (r2 permissions r3 permissions)

r1

(a) IRH

r2

(b) GRH

r3

r1

r3

r2

(c) Consolidated IRH and GRH

r1

r2

r3


Analysis of RB-RBAC


5. Inconsistency: Figure (b):

(r2 r3) r3 users have (r2 permissions r3 permissions)

r1

(a) IRH

r2

(b) GRH

r3

r1

r3

r2


r1

r2

r3


Analysis of RB-RBAC


5. Inconsistency: Figure (c):

The inconsistency manifests itself in the form of double arrows heading in the same direction between r2 and r3.

The enterprise business practice must be modified to remove this inconsistency.

r1

(a) IRH

r2

(b) GRH

r3

r1

r3

r2


r1

r2

r3


Conclusion

Seniority relations among authorization rules induce a role hierarchy (IRH).

IRH is a useful tool to check the compliance of current business practices to a given security policy.

IRH allows insight into what permissions to give to a specific rolewhich, in turn, assists in drawing lines of responsibility and authority.

Documents

SACMAT 03© Mohammad Al-Kahtani1 Induced Role Hierarchies with Attribute-Based RBAC Mohammad A. Al-Kahtani Ravi Sandhu George Mason University NSD Security,