Scalable Role Organization Based Access Control and Its

Scalable Role & Organization Based Access Control and Its Administration A Ph. D Dissertation Defense Zhixiong "Jim" Zhang Co-Director: Professor Ravi Sandhu Co-Director: Professor Daniel Menasce George Mason University Spring 2008 1

Presentation Outline • • • Introduction Motivating Examples Problem Summary ROBAC Models AROBAC 07 Model Manifold ROBAC and Secure Collaboration Contributions Future Work Q&A 2

Introduction • Wide adoption of RBAC in commercial software and enterprises in last decades • ANSI RBAC standard [2004] is based on RBAC 96 [1996] and NIST-RBAC [2001] • Existing large RBAC systems – Number of permissions: 1000 s – Number of roles: 1000 s – Number of users: 10, 000 s – 100, 000 s • Usually apply RBAC in one organization (B 2 E) 3

Traditional RBAC Model (RBAC 96 with ANSI RBAC Permission) Role Hierarchy (RH) User-Role Assignment (UA) Users Permission-Role Assignment (PA) Objects Roles Operations user ● ● . . ● roles Permissions (P) Sessions Constraints 4

Director (DIR) Project Lead 1 (PL 1) Project Lead 2 (PL 2) Production Engineer 1 (PE 1) Quality Engineer 1 (QE 1) Production Engineer 2 (PE 2) Quality Engineer 2 (QE 2) Engineer 1 (ENG 1) Engineer 2 (ENG 2) Engineering Department Staff (ED) Employee (EMP) (a) An example of regular role hierarchy in RBAC Senior Security Officer (SSD) Department Security Officer (DSO) Project Security Officer 1 (PSO 1) Project Security Officer 2 (PSO 2) (b) An example of administrative role hierarchy in ARBAC 97 5

Characteristics of Internet Based Applications • Large number of users (100 thousands to millions) • Involves many organizations (B 2 B) • Some user identifiers may be unknown in advance (B 2 C, user creates username via self-registration) • …… 6

Motivating Examples • B 2 B Example – Web-based report delivery System • B 2 C Example – Online subscription-based tutoring system 7

B 2 B Example • Web-based Report Delivery System – – 10, 000 s organizations (states, districts, schools in USA) 100 s types of reports 100, 000 s 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? 8

Using Traditional RBAC in the B 2 B 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 100 x 10000 permissions e. g. , p 1 – 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 p 1 9

B 2 C 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 10

Using Traditional RBAC in the B 2 C 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. , p 1 – can update Family_1’s profile • How many roles do we need? – Millions of roles e. g. , Family_1_parent role which has permission p 1 11

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 12

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 13

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: ROBAC 0, ROBAC 1, ROBAC 2, and ROBAC 3 14

ROBAC 0 Note: Changes From RBAC Blue - modified elements Red - new elements Assets (A) aorg atype Organizations Users (U) user Permission-Role Assignment (PA) Asset Types User-(Role, Org) Assignment (UA) (Roles, Orgs) ● ● . . ● Roles Operations active_role-orgs Sessions (S) Permissions (P)

ROBAC 0 Formal Definition • • ROBAC 0 has the following components: – U -- a set of users (same as U in RBAC 96); – S -- a set of sessions (same as S in RBAC 96); – R -- a set of roles (same as R in RBAC 96); – 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 16

ROBAC 0 Formal Definition (cont’d) • user: S U -- a function mapping a session si to a single user(si) (same as user in RBAC 96); • 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 2 RO -- a function mapping a user to a set of role-organization pairs assigned to the user; assigned_roleorgs(u) = (r, o) | (u, (r, o)) UA ; • active_role-orgs: S 2 RO -- 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 ; 17

can_access Predicate in ROBAC 0 • a 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. 18

ROBAC 1 Note: Changes From RBAC Blue - modified elements Red - new elements Assets (A) Organization Hierarchy (OH) aorg atype Organizations Users (U) user Permission-Role Assignment Role Hierarchy (PA) Asset Types (RH) User-(Role, Org) Assignment (UA) (Roles, Orgs) ● ● . . ● Roles Operations active_role-orgs Sessions (S) Permissions (P)

ROBAC Formal Definition (3) • ROBAC 1 has the following components : – U, S, R, O, Op, A, At, P, RO, PA, UA, user, atype, aorg -- same as those from ROBAC 0; – OH O O -- a partial order relation on O called organization hierarchy; – RH R R -- role hierarchy (same as RH in RBAC 96); – assigned_role-orgs: U 2 RO -- 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 2 RO -- a function mapping each session si to a set of active role-organization pairs; active_role-orgs(si) assigned_roleorgs(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 ) ; 20

ROBAC 2 Note: Changes From RBAC Blue - modified elements Red - new elements Assets (A) atype aorg Organizations Users (U) user Permission-Role Assignment (PA) Asset Types User-(Role, Org) Assignment (UA) (Roles, Orgs) ● ● . . ● Roles Operations active_role-orgs Permissions (P) Sessions (S) Constraints

ROBAC 3 Note: Changes From RBAC Blue - modified elements Red - new elements Assets (A) Organization Hierarchy (OH) atype aorg Organizations Users (U) user Permission-Role Assignment Role Hierarchy (PA) Asset Types (RH) User-(Role, Org) Assignment (UA) (Roles, Orgs) ● ● . . ● Roles Operations active_role-orgs Permissions (P) Sessions (S) Constraints

ROBAC Formal Definition (4) • ROBAC 2 is ROBAC 0 plus constraints, and ROBAC 3 is the consolidated model of ROBAC 1 and ROBAC 2 • 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 23

Separation of Duty Constraint • Separation of duty (So. D) constraints: Sod ( 2 RO+ x N ) where RO+ R O+; O+ = O { ? , *}; N is a natural number set such that (ros, n) So. D, |ros| ≥ n ≥ 2 • Static So. D: (ros, n) SSD, t ros: |t| ≥ n ≥ 2 => ∩ assigned_users((r, o)) = . (r, o) t • Dynamic So. D: (ros, n) DSD, s S, ro_subset 2 RO, ro_subset active_role-orgs(s), ro_subset ros => |ro_subset| n. 24

So. D Examples Element in So. D Meaning ( { (ri, ? ), (rj, ? )}, 2 ) no user can be assigned to both ri and rj for any same organization in O (global So. D). ( { (ri, ok), (rj, ol)}, 2 ) no user can be assigned to both ri in organization ok and rj in organization ol (local So. D). ( { (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. 25

Applying ROBAC to The B 2 B and B 2 C Examples • How many permissions and roles do we need for the B 2 B example? – Permissions: about the number of report types(100) e. g. , p 1 -- can access type_A_report – Roles: about the number of job functions e. g. , type_A_report_viewer role which has permission p 1 • How many roles do we need for the B 2 C example? – Two roles: parent and kid 26

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 27

ROBAC Applicability • homogeneous index, hindex: 2 R [0, 1] – a function mapping a role set to a number between 0 to 1 (including 0 and 1); formally, hindex(Rc) = |compatible_O*(Rc)| / |O| where compatible_O*(Rc) = { o | r Rc, (r, o) RO } e. g. hindex({parent, kid}) = 1 28

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 N M M Number of roles N M M Organization hierarchy N/A Yes Role hierarchy Yes Constraints Yes User-role-(org) assignment URA 97 UROA 07 (be covered in AROBAC 07) Permission-role assignment PRA 97 PRA 07 (be covered in AROBAC 07) Role administration RRA 97 RRA 07 (be covered in AROBAC 07) Number of role-org pairs N/A N M Role-org pairs administration N/A ROA 07 (be covered in AROBAC 07) Org administration N/A OOA 07 (be covered in AROBAC 07) 29

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) [LZQX 06] - 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 [KBBBCDMST 03] - Consider roles that subjects, actions or objects are assigned in an 30 organization

Existing Work on Role Based Administration • ARBAC 97 [SBM 99]: one of the most comprehensive role based administrative models. Three sub-models: URA 97 (user-role assignment), PRA 97 (permission-role assignment), and RRA 97 (role-role assignment) • ARBAC 02 [OSZ 06] enhances ARBAC 97 by incorporating two external organization structures: user organization structure (OS-U) and permission organization structure (OS-P) • SARBAC [CL 03] introduces a concept called administrative scope, which can be calculated for each role based on the role hierarchy • X-GTRBAC Admin [BJBG 04] uses admin domain concept to link users, roles, and permissions together 31

Director (DIR) Project Lead 1 (PL 1) Project Lead 2 (PL 2) Production Engineer 1 (PE 1) Quality Engineer 1 (QE 1) Production Engineer 2 (PE 2) Quality Engineer 2 (QE 2) Engineer 1 (ENG 1) Engineer 2 (ENG 2) Engineering Department Staff (ED) Employee (EMP) (a) An example of regular role hierarchy Senior Security Officer (SSD) Department Security Officer (DSO) Project Security Officer 1 (PSO 1) Project Security Officer 2 (PSO 2) (b) An example of administrative role hierarchy in ARBAC 97 32

AROBAC Model • Administrative ROBAC ’ 07 – It is a ROBAC approach to perform administrative tasks on ROBAC systems – Has five sub-models: • UROA 07 (user to role-organization pair assignment ’ 07) • PRA 07 (permission to role assignment ’ 07) • RRA 07 (role to role assignment ’ 07) • OOA 07 (organization to organization assignment ’ 07) • ROA 07 (role to organization assignment ’ 07) 33

AROBAC 07 Model Organization Hierarchy (OH) Assets aorg (A) atype Organizations UO Users (U) User-(Role, Org) Assignment (UA) (Roles, Orgs) user ● ● . . ● PO Role Hierarchy (RH) Permission-Role Assignment Regular Roles (PA) Operations ARRA active_role-orgs Asset Types Permissions (P ) Admin Roles Sessions (S) Constraints

Elements in AROBAC 07 (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 – regular role hierarchy (renamed RH in ROBAC); AR -- a set of administrative roles (same as AR in ARBAC 97), where RR AR=. ARH AR -- administrative role hierarchy (same as ARH in ARBAC 97); 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 UROA 07); 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 UROA 07); 35

Elements in AROBAC 07 (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 PRA 07); 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 PRA 07); can_modify_R : S 2 RR {true, false} -- a predicate which indicates that if can_modify_R(s, rset) is true then the user(s) can modify the roles and their relationship inside the role set rset within the session s (the definition is described in RRA 07); can_modify_O : S 2 O {true, false} -- a predicate which indicates that if can_modify_O(s, oset) is true then the user(s) can modify the organizations and their relationship inside the organization set oset within the session s (the definition is described in OOA 07); 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(s) can associate or disassociate role r with organization o within the session s (the definition is described in ROA 07); 36

UROA 07 Model • A user prerequisite condition (upc) is a boolean expression using the usual and operators on terms of form of (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 o O, 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 } 37

UROA 07 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 38

UROA 07 Grant Model • can_assign_user(s, u, (r, o)) is true iff ( o’ o, (ar, o’) active_role-orgs(s) ) ( c CRU, ((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 roleorg 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 39

UROA 07 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)). 40

UROA 07 Example 41

UROA 07 Example (2) • For example, a user with an active role-org pair (PSO, @PT 1) is a security administrator in project team 1 • may_manage_user(PSO, u, (PE, @PT 1), (QE, ? )) is true if user u is affiliated with project team 1 (@PT 1) and u is not a QE inside the project team 1 • The user with active role-org pair (PSO, @PT 1) 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, @PT 1) and (QE, @PT 1) 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 42

Manifold ROBAC • Manifold ROBAC (ROBACM) • aorg: A 2 O – a function mapping an asset to a subset of the organization set; • atype: A 2 At – a function mapping an asset to a subset of the asset type set; • can_access(S, Op, A) in ROBAC 0 M is slightly different from that in ROBAC 1 M. – In ROBAC 0 M, 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 ROBAC 1 M, 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 ) 43

Secure Collaboration • Gong and Qian [GQ 96]: 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 44

Related Work on Secure Collaboration • Secure interoperation using RBAC in multi-domain environments [KACM 00, JBBG 04, PJ 05, SJBG 05, TAPH 05, LZQX 06] • The most frequently used approach is to perform role translation or role mapping between different domains • Three types of violations when integrating RBAC policies [SJBG 05]: – user-specific separation of duty (So. D) violation – role-specific So. D violation – role-assignment violation • Most approaches have to handle many problems, such as covert role promotion, during the collaboration setup • Group-based RBAC [LZQX 06] addresses ad-hoc collaboration among different groups. It uses a permission-driven collaboration schema to eliminate role-mapping 45

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 46

Secure Collaboration Example Assets a 21 a 12 a 11 a 22 a 23 a 13 @PT 1 @PT 2 @VPT 12 Legend: @PT 1 – Project Team 1; @PT 2 – Project Team 2; @VPT 12 – Virtual Project Team under @PT 1 and @PT 2 a 11, a 12, a 13 are assets related to @PT 1; a 21, a 22, a 23 are assets related to @PT 2. 47

Secure Collaboration Example (cont. ) • • • Pre-collaboration state in the ROBAC system(note: only involved elements are listed here): – { a 11, a 12, a 13, a 21, a 22, a 23 } A; – aorg(a 1 i) = { @PT 1 }, i = 1, 2, 3; – aorg(a 2 i) = { @PT 2 }, i = 1, 2, 3; – atype(aij ) = { X } At, i = 1, 2; j = 1, 2, 3; – op Op, ( (op, X), ENG ) PA; Before collaboration: – (ENG, @PT 1) can access asset a 11, a 12, a 13 but not a 21, a 22, a 23 – (ENG, @PT 2) can access asset a 21, a 22, a 23 but not a 11, a 12, a 13 Collaboration grant: – Create a virtual project team @VPT 12 under @PT 1 and @PT 2 During collaboration: – (ENG, @PT 1) can access asset a 11, a 12, a 13, a 21, a 23 – (ENG, @PT 2) can access asset a 21, a 22, a 23, a 13 Collaboration Revoke: – Remove the @VPT 12 and all related association After Collaboration: – System returns to its original status automatically 48

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 AROBAC 07 is developed. It has five sub models: – – – UROA 07 is concerned with user to role and organization pair assignment; PRA 07 deals with permission-role assignment; RRA 07 manages roles and role hierarchy; OOA 07 handles organizations and organization hierarchy; ROA 07 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. 49

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 ondemand movie service. 50

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 [PST 91]; • Integrate general constraints in ROBAC; • Detail the implementation perspective of ROBACM based secure collaboration schema; • …… 51

Published Papers On This Topic • [ZZS 06] Zhixiong Zhang, Xinwen Zhang, and Ravi Sandhu, “ROBAC: Scalable Role and Organization Based Access Control Models”, Proceedings of Collaborate. Com-2006/Trust. Col-2006, Atlanta, Georgia, USA, November 2006. • [ZZS 07] 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. 52

Thank You • Questions? 53