1 Scalable Role & Organization Based Access Control and Its Administration A PhD Dissertation...

1

Scalable Role & Organization Based Access Control and Its Administration

A PhD Dissertation DefenseZhixiong "Jim" Zhang

Co-Director: Professor Ravi SandhuCo-Director: Professor Daniel Menasce

George Mason UniversitySpring 2008

2

Presentation Outline

• Introduction• Motivating Examples • Problem Summary• ROBAC Models• AROBAC07 Model• Manifold ROBAC and Secure Collaboration• Contributions • Future Work• Q & A

3

Introduction

• Wide adoption of RBAC in commercial software and enterprises in last decades

• ANSI RBAC standard [2004] is based on RBAC96 [1996] and NIST-RBAC [2001]

• Existing large RBAC systems – Number of permissions: 1000s – Number of roles: 1000s– Number of users: 10,000s – 100,000s

• Usually apply RBAC in one organization (B2E)

4

User-RoleAssignment

(UA)

Users Roles

Permission-RoleAssignment

(PA)

●

●

.

.●

Sessions

Role Hierarchy (RH)

Constraints

user roles Permissions(P)

Operations

Objects

Traditional RBAC Model (RBAC96 with ANSI RBAC Permission)

5

Director (DIR)

Project Lead 1 (PL1)

Production Engineer 1 (PE1) Quality Engineer 1 (QE1)

Engineer 1 (ENG1)

Engineering Department Staff (ED)

(a) An example of regular role hierarchy in RBAC

Senior Security Officer (SSD)

Department Security Officer (DSO)

Project Security Officer 1 (PSO1)

(b) An example of administrative role hierarchy in ARBAC97



Engineer 2 (ENG2)

Employee (EMP)


6

• Large number of users (100 thousands to millions)

• Involves many organizations (B2B)

• Some user identifiers may be unknown in advance (B2C, user creates username via self-registration)

• ……

Characteristics of Internet Based Applications

7

Motivating Examples

• B2B Example– Web-based report delivery System

• B2C Example– Online subscription-based tutoring system

8

B2B Example

• Web-based Report Delivery System– 10,000s organizations (states, districts, schools in USA)– 100s types of reports– 100,000s end users– Some constraints, such as

• An organization only can access its own reports and its subordinate’s reports

• A school principle can access some types of his/her school’s reports but it cannot access other types of his/her school’s reports which can be access by the school’s consoler

• How to apply RBAC here?

9

Using Traditional RBAC in the B2B example

• How many permissions do we need?– Access type_A_report_for_school_1 is different from

access type_A_report_for_school_2– May need 100x10000 permissions

e.g., p1 – can access type_A_report_for_school_1

• How many roles do we need?– 10,000 x number of report types

e.g., school_1_type_A_report_viewer role which has permission p1

10

B2C Example

• Online subscription-based tutoring system ( its customers are families whose children are elementary school students)– Millions of families– Parents can pay subscription fee, create /

update the family profile, and view their children’s progress reports

– Children can take lessons, view their family profile, and their progress reports on the web

11

Using Traditional RBAC in the B2C example

• How many permissions do we need?– updating family_1_profile is different from the

updating family_2_profile– May need millions permissions e.g., p1 – can update Family_1’s profile

• How many roles do we need?– Millions of rolese.g., Family_1_parent role which has

permission p1

12

Efforts to Scale Up RBAC

• Giuri and Iglio [1997]: Role Templates– parameterized privilege– restricting access to a subset of contents

• Thomas [1997]: Team-based Access Control (TMAC)– scalable permission assignment and fine-grained, run-time

permission activation at the level of individual users and objects• Perwaiz and Sommerville [2001]: Organizational Units

– a mechanism for viewing role-permission relationships in the context of organizational structures

• Park et al. [2004]: Composite RBAC for large and complex organizations– categorizes roles into different classes and maps roles between

them to achieve role class reusability and scalability

13

Problem Summary

• Most existing RBAC and ARABC models do not scale up well when applying to applications involving a large number of organizations

• Several RBAC extensions try to address RBAC scalability problem in the context of one enterprise but lack either formalization or systematic administrative models

14

Solution: ROBAC Models

• Informal description:– Utilize both role and organization information

during the authorization process in order to reduce the number of permissions and roles

• Four models: ROBAC0, ROBAC1, ROBAC2, and ROBAC3

User-(Role, Org)Assignment

(UA)Users

(U) (Roles, Orgs)


(PA)

●

●

.

.●

Sessions(S)

useractive_role-orgs

Organizations

Permissions(P)

Operations

Asset Types

Roles

Assets (A)

aorg atype

ROBAC0Note: Changes From RBACBlue - modified elementsRed - new elements

16

ROBAC0 Formal Definition

• ROBAC0 has the following components:– U -- a set of users (same as U in RBAC96);– S -- a set of sessions (same as S in RBAC96);– R -- a set of roles (same as R in RBAC96);– O -- a set of organizations;– Op -- a set of operations;– A -- a set of assets;– At -- a set of asset types;– P Op At -- a set of permissions;– RO R O -- a set of applicable role and organization associations;– PA P R -- a many-to-many permission-to-role assignment relation;– UA U RO -- a many-to-many user-to-role-and-organization

assignment relation; • to be continued

17

ROBAC0 Formal Definition (cont’d)

• user: S U -- a function mapping a session si to a single user user(si) (same as user in RBAC96);

• atype: A At -- a function mapping an asset to its type;• aorg: A O -- a function mapping an asset to the organization it

relates to; • assigned_role-orgs: U 2RO -- a function mapping a user to a set of

role-organization pairs assigned to the user; assigned_role-orgs(u) = (r,o) | (u, (r,o)) UA ;

• active_role-orgs: S 2RO -- a function mapping a session si to a set of active role-organization pairs;

active_role-orgs(si) assigned_role-orgs(user(si));• can_access: S Op A {true, false} -- a predicate defined as

can_access(s, op, a) is true iff (r, o) active_role-orgs(s) aorg(a) = o ((op, atype(a)), r) PA ;

18

can_access Predicate in ROBAC0

• a user user(s) in a session s can perform an operation op over an asset a if and only if the user has an active role and organization pair (r, o) in the session and role r has permission to perform operation op over asset a’s type and asset a is related to organization o.


(UA)Users

(U) (Roles, Orgs)


(PA)

●

●

.

.●

Sessions(S)


Organizations

Permissions(P)

Operations

Asset Types

Roles

Assets (A)

aorg atype


Organization Hierarchy (OH)

Role Hierarchy (RH)

20

ROBAC Formal Definition (3)• ROBAC1 has the following components :

– U, S, R, O, Op, A, At, P, RO, PA, UA, user, atype, aorg -- same as those from ROBAC0;

– OH O O -- a partial order relation on O called organization hierarchy;

– RH R R -- role hierarchy (same as RH in RBAC96); – assigned_role-orgs: U 2RO -- a function mapping a user to a set of

role-organization pairs assigned to the user; assigned_role-orgs(u) = (r,o) | r’ r o’ o (u, (r’,o’)) UA ;

– active_role-orgs: S 2RO -- a function mapping each session si to a set of active role-organization pairs; active_role-orgs(si) assigned_role-orgs(user(si));

– can_access : S Op A {true, false} – a predicate defined as can_access(s, op, a) is true iff (r, o) active_role-orgs(s) aorg(a) o ( r’ r, ((op, atype(a)), r’) PA ) ;


(UA)Users

(U) (Roles, Orgs)


(PA)

●

●

.

.●

Sessions(S)


Organizations

Permissions(P)

Operations

Asset Types

Roles

Assets (A)

aorg atype


Constraints


(UA)Users

(U) (Roles, Orgs)


(PA)

●

●

.

.●

Sessions(S)


Organizations

Permissions(P)

Operations

Asset Types

Roles

Assets (A)

aorg atype



Role Hierarchy (RH)

Constraints

23

ROBAC Formal Definition (4)

• ROBAC2 is ROBAC0 plus constraints, and ROBAC3 is the consolidated model of ROBAC1 and ROBAC2

• Constraints can be defined on RO, role activations (sessions), UA, and PA

• Two levels of constraints– Global constraints: applicable to all organizations– Local constraints: applicable to specified

organizations

24

Separation of Duty Constraint

• Separation of duty (SoD) constraints: Sod ( 2RO+ x N ) where RO+ RO+; O+ = O { ?, *};

N is a natural number set such that (ros, n) SoD, |ros| ≥ n ≥ 2

• Static SoD: (ros, n) SSD, t ros: |t| ≥ n ≥ 2 => ∩ assigned_users((r,o)) = .

(r,o) t

• Dynamic SoD: (ros, n) DSD, s S, ro_subset 2RO, ro_subset active_role-orgs(s), ro_subset ros => |ro_subset| n.

25

SoD ExamplesElement in SoD Meaning

( { (ri, ?), (rj, ?)}, 2 ) no user can be assigned to both ri and rj for any same organization in O (global SoD).

( { (ri, ok), (rj, ol)}, 2 ) no user can be assigned to both ri in organization ok and rj in organization ol (local SoD).

( { (ri, ok), (rj, ?)}, 2 ) no user can be assigned to ri in organization ok while the user has role rj in any organization.

( { (ri, ok), (rj, *)}, 2 ) same as above.

( { (ri, *), (rj, *) }, 2 ) no user can be assigned to both ri and rj in any organizations in O.

26

Applying ROBAC to The B2B and

B2C Examples • How many permissions and roles do we

need for the B2B example?– Permissions: about the number of report types(100)

e.g., p1 -- can access type_A_report

– Roles: about the number of job functions

e.g., type_A_report_viewer role which has permission p1

• How many roles do we need for the B2C example?– Two roles: parent and kid

27

When Using ROBAC?

• Using ROBAC when situation involves many organizations and job functions are similar across organizations

• Not using ROBAC when there is no job function similarity across organizations

28

ROBAC Applicability

• homogeneous index, hindex: 2R [0, 1] – a function mapping a role set to a number between 0 to1 (including 0 and1);

formally,

hindex(Rc) = |compatible_O*(Rc)| / |O|

wherecompatible_O*(Rc) = { o | r Rc, (r, o) RO }

e.g. hindex({parent, kid}) = 1

29

Comparison with Classic RBAC |Rc|RBAC = |O| [ 1 + ( |Rc|ROBAC -1 ) hindex(Rc) ]

Best scenario for N organizations and M job titles RBAC ROBAC

Number of permissions NM M

Number of roles NM M

Organization hierarchy N/A Yes

Role hierarchy Yes Yes

Constraints Yes Yes

User-role-(org) assignment

URA97 UROA07 (be covered in AROBAC07)

Permission-role assignment

PRA97 PRA07(be covered in AROBAC07)

Role administration RRA97 RRA07(be covered in AROBAC07)

Number of role-org pairs

N/A NM

Role-org pairs administration

N/A ROA07(be covered in AROBAC07)

Org administration N/A OOA07(be covered in AROBAC07)

30

Comparison with Some RBAC Extensions

• Role templates [Giuri and Iglio, 1997]– parameterized privilege– restricting access to a subset of contents

• Team-based Access Control (TMAC) [Thomas, 1997]– scalable permission assignment and fine-grained, run-time permission

activation at the level of individual users and objects • Organizational Units [Perwaiz and Sommerville, 2001]

– permissions of a role in an organization unit are the intersection of the role’s permissions and the organization unit’s permissions

• Organization Entity in Credential Based Access Control [Biskup and Wortmann, 2004] – a collection of objects (assets) those may belong to different owners

and act like a namespace• Comparison with Group Based RBAC (GB-RBAC) [LZQX06]

- Roles in GB-RBAC are divided as group roles and user roles. - Groups are assigned to group roles. Users are assigned to user roles.

• Comparison with Organization Based Access Control [KBBBCDMST03]- Consider roles that subjects, actions or objects are assigned in an organization

31

Existing Work on Role Based Administration

• ARBAC97 [SBM99]: one of the most comprehensive role based administrative models. Three sub-models: URA97 (user-role assignment), PRA97 (permission-role assignment), and RRA97 (role-role assignment)

• ARBAC02 [OSZ06] enhances ARBAC97 by incorporating two external organization structures: user organization structure (OS-U) and permission organization structure (OS-P)

• SARBAC [CL03] introduces a concept called administrative scope, which can be calculated for each role based on the role hierarchy

• X-GTRBAC Admin [BJBG04] uses admin domain concept to link users, roles, and permissions together

32

Director (DIR)



Engineer 1 (ENG1)

Engineering Department Staff (ED)

(a) An example of regular role hierarchy

Senior Security Officer (SSD)

Department Security Officer (DSO)


(b) An example of administrative role hierarchy in ARBAC97



Engineer 2 (ENG2)

Employee (EMP)


33

AROBAC Model

• Administrative ROBAC ’07– It is a ROBAC approach to perform

administrative tasks on ROBAC systems– Has five sub-models:

• UROA07 (user to role-organization pair assignment ’07)

• PRA07 (permission to role assignment ’07)• RRA07 (role to role assignment ’07)• OOA07 (organization to organization assignment

’07)• ROA07 (role to organization assignment ’07)


(UA)Users

(U)(Roles, Orgs)


(PA)

●

●

.

.●

Sessions(S)

Constraints

user active_role-orgs

Organizations


Permissions

(P)

Operations

Asset Types

Regular Roles

Role Hierarchy (RH)

Assets (A)aorg

atype

Admin Roles

UO

PO

ARRA

AROBAC07 Model

35

Elements in AROBAC07 (1)• U, S, O, OH, Op, A, At, P, RO, PA, UA, user, atype, aorg, assigned_role-orgs, active_role-orgs,

can_access -- same as those from ROBAC;• RR -- a set of regular roles (renamed R in ROBAC);• RRH RR RR – regular role hierarchy (renamed RH in ROBAC);• AR -- a set of administrative roles (same as AR in ARBAC97), where RR AR=. • ARH AR AR -- administrative role hierarchy (same as ARH in ARBAC97);• R = RR AR -- the set of all roles;• ARRA AR RR -- a many-to-many administrative role to regular role assignment;• RH = RRH ARH -- a combined role hierarchy;• UO U O -- a set of user-organization affiliations;• PO P O -- a set of applicable permission-organization associations;• CRU – a set of applicable prerequisite condition for users;• CRP – a set of applicable prerequisite condition for permissions;• CAN_ASSIGN_USER ARRA CRU - an association defines the constraints when assigning

users to role-organization pairs;• CAN_REVOKE_USER ARRA CRU - an association defines the constraints when revoking

users from role-organization pairs;• can_assign_user: S U RO {true, false} – a predicate which indicates that if

can_assign_user(s, u, (r,o)) is true then user u can be assigned to the role-org pair (r,o) within the session s (the definition is described in UROA07);

• can_revoke_user: S U RO {true, false} – a predicate which indicates that if can_revoke_user(s, u, (r,o), c) is true then user u can be revoked from role-org pair (r,o) within the session s (the definition is described in UROA07);

36

Elements in AROBAC07 (2)• CAN_ASSIGN_PERMISSION ARRA CRP - an association defines the

constraints when assigning permissions to roles;• CAN_REVOKE_PERMISSION ARRA CRP - an association defines the

constraints when revoking permissions from roles;• can_assign_permission: S P RR {true, false} – a predicate which indicates

that if can_assign_permission(s, p, r) is true then the permission p can be assigned to the regular role r within the session s (the definition is described in PRA07);

• can_revoke_permission : S P RR {true, false} – a predicate which indicates that if can_revoke_permission(s, p, r) is true then the permission p can be revoked from the regular role r within the session s (the definition is described in PRA07);

• can_modify_R : S 2RR {true, false} -- a predicate which indicates that if can_modify_R(s, rset) is true then the user user(s) can modify the roles and their relationship inside the role set rset within the session s (the definition is described in RRA07);

• can_modify_O : S 2O {true, false} -- a predicate which indicates that if can_modify_O(s, oset) is true then the user user(s) can modify the organizations and their relationship inside the organization set oset within the session s (the definition is described in OOA07);

• can_modify_RO : S R O {true, false} -- a predicate which indicates that if can_modify_RO(s, r, o) is true then the user user(s) can associate or disassociate role r with organization o within the session s (the definition is described in ROA07);

37

UROA07 Model

• A user prerequisite condition (upc) is a boolean expression using the usual and operators on terms of form of (r, ?), (r, ?), (r, o), and (r, o) where (r, o) is a role-org pair belongs to RO. A user prerequisite condition is evaluated for a user u by interpreting (r, o) to be true if (r’ r, o’ o) (u, (r’, o’)) UA and (r, o) is true if (r, o) is not true. Here “?” is a place holder for any oO, and (r, ?) is true for user u if (r’ r , o’ ?, (u, (r’, o’)) UA ) and (r, ?) is true if (r, ?) is not true. CRU is a set including all applicable upcs plus a null element. The null is interpreted as true for any user

• omembers*(o) = { u | o’ o, (u, o’) UO } • apermissions*(ar) = {r | ar’ ar, (ar’, r)ARRA }

38

UROA07 Model (2)

• may_manage_user : AR U RO CRU {true, false} - a predicate defined as may_manage_user(ar, u, (r,o), c) is true iff (r apermissions*(ar)) c (u omembers*(o))

• an administrative role ar may manage the user u with respect to the role-org pair (r, o) if and only if the user u satisfies the user prerequisite condition c and is affiliated to the organization o or its subordinate organizations and the administrative role ar or its junior administrative roles can perform administrative tasks on role r

39

UROA07 Grant Model

• can_assign_user(s, u, (r,o)) is true iff (o’ o, (ar, o’) active_role-orgs(s) ) (cCRU, ((ar, r),c) CAN_ASSIGN_USER may_manage_user(ar, u, (r,o), c))

• a user (user(s)) in a session s can assign a user u to a role-org pair (r, o) if and only if user(s) has an active role-org pair (ar, o) (explicitly or implicitly via organization hierarchy) in that session and user u satisfies all related user prerequisite conditions defined in CAN_ASSIGN_USER and is affiliated to the organization o or its subordinate organizations and the administrative role ar or its junior administrative roles can perform administrative tasks on role r

40

UROA07 Revoke Model

• can_revoke_user : S U RO {true, false}, a predicate controls whether a user can be revoked from a role-org pair within a session. It is defined as

can_revoke_user(s, u, (r,o)) is true iff (o’ o, (ar, o’) active_role-orgs(s) ) (c, ((ar, r), c) CAN_REVOKE_USER may_manage_user(ar, u, (r,o), c)).

41

UROA07 Example

42

UROA07 Example (2)• For example, a user with an active role-org pair (PSO, @PT1) is a

security administrator in project team 1 • may_manage_user(PSO, u, (PE, @PT1), (QE, ?)) is true if user u

is affiliated with project team 1 (@PT1) and u is not a QE inside the project team 1

• The user with active role-org pair (PSO, @PT1) can assign membership of roles: PL, PE, QE, and ENG within project team 1, to users affiliated with the project team 1 but cannot assign these users to roles within project team 2 and cannot assign users not affiliated to project team 1 to any roles

• Cannot assign both (PE, @PT1) and (QE, @PT1) to the same user because of the user prerequisite conditions, ((PSO, PE), (QE, ?)) and ((PSO, QE), (PE, ?)) , defined in CAN_ASSIGN_USER at above figure (d), which represents a global separation of duty constraint in ROBAC

43

Manifold ROBAC

• Manifold ROBAC (ROBACM)• aorg: A 2O – a function mapping an asset to a subset of the

organization set;• atype: A 2At – a function mapping an asset to a subset of the

asset type set;

• can_access(S, Op, A) in ROBAC0M is slightly different from that in

ROBAC1M.

– In ROBAC0M, can_access(s, op, a) is true iff (r, o)

active_role-orgs(s) o aorg(a) ( at atype(a), ((op, at), r) PA )

– In ROBAC1M, can_access(s, op, a) is true iff (r, o)

active_role-orgs(s) ( o’ aorg(a), o’ o ) (at atype(a), r’ r, ((op, at), r’) PA )

44

Secure Collaboration

• Gong and Qian [GQ96]: two secure collaboration principles:– Autonomy: any allowed access in an

individual system must also be allowed under secure interoperation

– Security: any denied access in an individual system must also be denied under secure interoperation

45

Related Work on Secure Collaboration

• Secure interoperation using RBAC in multi-domain environments [KACM00, JBBG04, PJ05, SJBG05, TAPH05, LZQX06]

• The most frequently used approach is to perform role translation or role mapping between different domains

• Three types of violations when integrating RBAC policies [SJBG05]:– user-specific separation of duty (SoD) violation– role-specific SoD violation– role-assignment violation

• Most approaches have to handle many problems, such as covert role promotion, during the collaboration setup

• Group-based RBAC [LZQX06] addresses ad-hoc collaboration among different groups. It uses a permission-driven collaboration schema to eliminate role-mapping

46

Secure Collaboration with ROBACM

• Main idea:– For a collaboration request, we create a virtual

organization and make it as a subordinate of all participating organizations in the organization hierarchy

– An administrator of a participating organization sets any of its want-to-be-shared assets as also related to the virtual organization

– Our method is simpler and cleaner

47

Secure Collaboration Example

a11

@PT1 @PT2

@VPT12

a12

a13

a21 a22

a23

Legend: @PT1 – Project Team 1; @PT2 – Project Team 2; @VPT12 – Virtual Project Team under @PT1 and @PT2 a11, a12,a13 are assets related to @PT1; a21, a22, a23 are assets related to @PT2.

Assets

48

Secure Collaboration Example (cont.)• Pre-collaboration state in the ROBAC system(note: only involved elements are listed here):

– { a11, a12, a13, a21, a22, a23 } A;

– aorg(a1i) = { @PT1 }, i = 1, 2, 3;

– aorg(a2i) = { @PT2 }, i = 1, 2, 3;

– atype(aij ) = { X } At, i = 1, 2; j = 1, 2, 3;

op Op, ( (op, X), ENG ) PA;• Before collaboration:

– (ENG, @PT1) can access asset a11, a12, a13 but not a21, a22, a23– (ENG, @PT2) can access asset a21, a22, a23 but not a11, a12, a13

• Collaboration grant:– Create a virtual project team @VPT12 under @PT1 and @PT2

• During collaboration:– (ENG, @PT1) can access asset a11, a12, a13, a21, a23 – (ENG, @PT2) can access asset a21, a22, a23, a13

• Collaboration Revoke:– Remove the @VPT12 and all related association

• After Collaboration:– System returns to its original status automatically

49

Contributions

• A family of extended RBAC models called Role and Organization Based Access Control (ROBAC) models is proposed and formalized. It scales up well for applications involving many similar organizations. Its applicability and expressive power are discussed.

• A comprehensive role and organization based administrative model called AROBAC07 is developed. It has five sub models:

– UROA07 is concerned with user to role and organization pair assignment; – PRA07 deals with permission-role assignment; – RRA07 manages roles and role hierarchy; – OOA07 handles organizations and organization hierarchy; – ROA07 controls applicable association between roles and organizations.

• A concept called application compartment (ACom) in ROBAC is introduced and its usage in ROBAC / AROBAC is discussed.

50

Contributions (2)

• Two ROBAC variants, manifold ROBAC and pseudo ROBAC, and their corresponding administrative models are presented.

• A manifold ROBAC based secure collaboration schema is proposed and formalized. The schema avoids many problems resulted from role-mapping or role-transformation. It is simpler and cleaner than existing role based secure collaboration approaches.

• The usefulness of pseudo ROBAC is demonstrated in an on-demand movie service.

51

Future Work

• Explore the enforcement and implementation aspects of ROBAC;

• Perform safety analysis in ROBAC;• Detail the implication of can_modify_R, can_modify_O,

and can_modify_RO predicates on individual administrative tasks such as add/delete nodes or edges;

• Define each administrative action using some formal specification language such as Z [PST91];

• Integrate general constraints in ROBAC;• Detail the implementation perspective of ROBACM based

secure collaboration schema;• ……

52

Published Papers On This Topic

• [ZZS06] Zhixiong Zhang, Xinwen Zhang, and Ravi Sandhu, “ROBAC: Scalable Role and Organization Based Access Control Models”, Proceedings of CollaborateCom-2006/TrustCol-2006, Atlanta, Georgia, USA, November 2006.

• [ZZS07] Zhixiong Zhang, Xinwen Zhang, and Ravi Sandhu, “Towards a Scalable Role and Organization Based Access Control Model with Decentralized Security Administration”, in Manish Gupta and Raj Sharman edit: “Handbook of Research on Social and Organizational Liabilities in Information Security”, IGI Global publications. Accepted for publishing at April 2007.

53

Thank You

• Questions?

Date post:	26-Mar-2015
Category:	Documents
Upload:	brian-donnelly
View:	218 times
Download:	3 times

1 Scalable Role & Organization Based Access Control and Its Administration A PhD Dissertation...

Documents