Presentation is loading. Please wait.

Presentation is loading. Please wait.

A PhD Dissertation Defense Zhixiong "Jim" Zhang

Similar presentations


Presentation on theme: "A PhD Dissertation Defense Zhixiong "Jim" Zhang"— Presentation transcript:

1 Scalable Role & Organization Based Access Control and Its Administration
A PhD Dissertation Defense Zhixiong "Jim" Zhang Co-Director: Professor Ravi Sandhu Co-Director: Professor Daniel Menasce George Mason University Spring 2008 My dear committee members and fellow students. Thanks for coming. My dissertation title is Scalable Role and Organization Based Access Control. Dr. Sandhu and Dr. Menasce are my dissertation directors. As you know that Dr. Sandhu moved to University of Texas and he is joining us via Web conference today.

2 Presentation Outline Introduction Motivating Examples Problem Summary
ROBAC Models AROBAC07 Model Manifold ROBAC and Secure Collaboration Contributions Future Work Q & A Here is an outline for today’s presentation. I will talk about the background and motivation behind the ROBAC models. Summarize the problem I try to address in my dissertation. Present my solution: ROBAC models. Then present an administrative ROBAC model called AROBAC07. After that, I will talk about some ROBAC variation: one of them is called manifold ROBAC. I will show its application in secure collaboration. Finally, I will summarize my contributions and discuss some future work. There will be Question and Answer session after my presentation. You are also welcome to ask me questions during the presentation.

3 Introduction Usually apply RBAC in one organization (B2E)
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 Traditional RBAC Model (RBAC96 with ANSI RBAC Permission)
Role Hierarchy (RH) User-Role Assignment (UA) Permission-Role Assignment (PA) Users Roles Objects Operations user . roles Permissions (P) Based on well-known RBAC96 with the permission definition from ANSI RBAC. Due to indirect assignment between users and permissions, RBAC scales up better than MAC (Mandatory Access Control) and DAC (Discretional Access Control) with respect to the number of users. However, RBAC does not scale up well with respect to the number of roles and permissions. Administrative tasks: user to role assignment; permission to role assignment; role to role assignment (manage role hierarchy). Managing permissions and roles are usually manual tasks. Huge administrative burden and error-prone if there are a large number of permissions and roles and/or there are frequently changes on permissions and roles. Centralize administration: super users Role based de-centralized administration: separate administrative roles and utilize underline RBAC to control administrative tasks. Sessions Constraints

5 5 Director (DIR) Project Lead 1 (PL1) Project Lead 2 (PL2)
Production Engineer 1 (PE1) Quality Engineer 1 (QE1) Production Engineer 2 (PE2) Quality Engineer 2 (QE2) Engineer 1 (ENG1) Engineer 2 (ENG2) Engineering Department Staff (ED) Employee (EMP) (a) An example of regular role hierarchy in RBAC The Figure (a) shows an example of regular role and role hierarchy in classic RBAC system. The Figure (b) shows an example of administrative role and administrative role hierarchy in classic RBAC system with role based administration. Senior Security Officer (SSD) Department Security Officer (DSO) Project Security Officer 1 (PSO1) Project Security Officer 2 (PSO2) (b) An example of administrative role hierarchy in ARBAC97 5

6 Characteristics of Internet Based Applications
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) …… More Internet based applications.

7 Motivating Examples B2B Example B2C Example
Web-based report delivery System B2C Example Online subscription-based tutoring system

8 B2B Example Web-based Report Delivery System How to apply RBAC here?
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? About 6 years ago, I was asked to develop an authentication and authorization sub-system for a web based report delivery application. This example is an abstraction from that application.

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 Applying traditional RBAC directly will result large number of permissions and roles.

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 roles e.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 RBAC models have been extended from various aspects (temporal, spatial, location-aware, or context-aware) to better meet the needs in the real world. Here are some effort to scale up RBAC. Most extensions consider RBAC in the context of one organization.

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 Define four models one by one based on the increasing security functionality of the models. ROBAC0 is base model (flat model). ROBAC1 is ROBAC0 plus role hierarchy and organization hierarchy. ROBAC2 is ROBAC0 plus constraints. ROBAC3 is ROBAC0 plus role hierarchy, organization hierarchy and constraints.

15 ROBAC0 . user ● active_role-orgs Note: Changes From RBAC
Blue - modified elements Red - new elements Assets (A) atype aorg Organizations Permission-Role Assignment (PA) User-(Role, Org) Assignment (UA) Asset Types Users (U) (Roles, Orgs) Roles Operations . user ROBAC0 is a base model which is an extension of the flat RBAC model. The blue elements are modified elements. The red are newly added elements. active_role-orgs Permissions (P) Sessions (S)

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 Blue: modified elements; Red: new elements. 16

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 ; ROBAC0 extends RBAC0 by: introducing new sets: Organizations (O), Asset Types (At), and Role-Organization pairs (RO) Introducing new functions: atype and aorg Extending assigned-role and roles (session-role) to assigned-role-orgs and active-role-orgs Redefining permissions (P) and user to role assignment (UA) Introducing a predicate: can_access(s, op, a) 17

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. Any authorization service need to answer the following question: whether a user (subject) can perform a operation (action) on an object (asset) in a session. The can_access predicate in ROBAC defines the logic for answering this question. The logic in ROBAC is different from the logic in RBAC.

19 Organization Hierarchy
ROBAC1 Note: Changes From RBAC Blue - modified elements Red - new elements Organization Hierarchy (OH) Assets (A) atype aorg Organizations Permission-Role Assignment (PA) Role Hierarchy (RH) User-(Role, Org) Assignment (UA) Asset Types Users (U) (Roles, Orgs) Roles Operations . user ROBAC1 is a base model plus role hierarchy and organization hierarchy. The blue elements are modified elements. The red are newly added elements. active_role-orgs Permissions (P) Sessions (S)

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 ) ; 20

21 ROBAC2 . Constraints user ● active_role-orgs Note: Changes From RBAC
Blue - modified elements Red - new elements Assets (A) atype aorg Organizations Permission-Role Assignment (PA) User-(Role, Org) Assignment (UA) Asset Types Users (U) (Roles, Orgs) Roles Operations . user ROBAC2 is a base model plus constraints. The blue elements are modified elements. The red are newly added elements. active_role-orgs Permissions (P) Sessions (S) Constraints

22 Organization Hierarchy
ROBAC3 Note: Changes From RBAC Blue - modified elements Red - new elements Organization Hierarchy (OH) Assets (A) atype aorg Organizations Permission-Role Assignment (PA) Role Hierarchy (RH) User-(Role, Org) Assignment (UA) Asset Types Users (U) (Roles, Orgs) Roles Operations . user ROBAC3 is a combine model which includes all elements. The blue elements are modified elements. The red are newly added elements. active_role-orgs Permissions (P) Sessions (S) 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 We explain these two levels of constraints by using one of the most common UA constraints: separation of duty. 23

24 Separation of Duty Constraint
Separation of duty (SoD) constraints: Sod  ( 2RO+ x N ) where RO+  RO+; 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. 24

25 SoD Examples Element 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. The difference between wild character ‘?’ and ‘*’ is that all occurrences of ‘?’ will take the same value from O while the different occurrences of ‘*’ can take different values from O. 25

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| where compatible_O*(Rc) = { o | r  Rc, (r, o)  RO } e.g. hindex({parent, kid}) = 1 What is the best scenario for using ROBAC? Here we try to categorize ROBAC from the applicability perspective. The higher the hindex(R) value is, the more benefit we can get by applying ROBAC. The best scenario is that the ROBAC is totally homogeneous on the role set R, that is hindex(R) = 1. The worst scenario for ROBAC is that the ROBAC is heterogeneous on all subsets of the role set R, that is,  Rc  R and Rc   hindex(Rc) = 1/|O| The hindex function gives us some quantified value on how well the ROBAC model is used for a given problem. The ROBAC in the B2C example is totally homogeneous on {parent, kid}. 28

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 NM M Number of roles Organization hierarchy N/A Yes Role hierarchy Constraints User-role-(org) assignment URA97 UROA07 (be covered in AROBAC07) Permission-role assignment PRA97 PRA07 Role administration RRA97 RRA07 Number of role-org pairs Role-org pairs administration ROA07 Org administration OOA07 For a set of job function Rc, we show the relationship between the number of possible roles in classic RBAC and the number of possible roles in ROBAC. When some degree of homogeneous exists in a ROBAC system, the number of permissions in ROBAC is less than the number of permissions in classic RBAC. That results in a smaller number of roles in ROBAC than that in RBAC. The number of permissions and roles do not increase when new organizations are added if the newly added organizations compatible with some existing organizations on some role set and no new job functions are introduced in the new organization. That reduces administrative efforts significantly. For totally homogeneous ROBAC, hindex(R) = 1 |R|RBAC = |O|  |R|ROBAC That is the number of roles in classic RBAC is |O| times more than the number of roles in ROBAC. For heterogeneous ROBAC, hindex(R) = 1 / |O| |R|RBAC = |O| + |R|ROBAC - 1 Because none of organizations share job functionality, we can treat the ROBAC as having one big organization. That is, |O| = 1, |R|RBAC = |O| + |R|ROBAC = |R|ROBAC 29

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 30

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 There are two main approaches to perform RBAC administration. One is centralized such as Gavrila and Barkley’s NIST model [GB98] and Nyanchama and Osborn’s role graph model [NO99] where one or more security administrators perform all administrative tasks. Another is decentralized such as Sandhu et al’s ARBAC97 model [SBM99], Crampton and Loizou’s SARBAC model [CL03], Oh et al’s ARBAC02 model [OSZ06], and Bhatti et al’s X-GTRBAC admin [BJBG04] where administrative tasks are distributed among many different administrators in a controlled manner. These role based decentralized approaches usually add a separate administrative role hierarchy in the original RBAC model.

32 Director (DIR) Project Lead 1 (PL1) Project Lead 2 (PL2) Production Engineer 1 (PE1) Quality Engineer 1 (QE1) Production Engineer 2 (PE2) Quality Engineer 2 (QE2) Engineer 1 (ENG1) Engineer 2 (ENG2) Engineering Department Staff (ED) Employee (EMP) (a) An example of regular role hierarchy Here is an extract from ARABC97. Senior Security Officer (SSD) Department Security Officer (DSO) Project Security Officer 1 (PSO1) Project Security Officer 2 (PSO2) (b) An example of administrative role hierarchy in ARBAC97

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) Following the ARBAC97 approach, we divide administrative tasks into the following categories: assigning users to role-organization pairs, assigning permissions to roles, managing roles and role hierarchy, managing organization and organization hierarchy, and managing role and organization association. The reason is that these administrative activities in ROBAC affect user’s access rights in different ways.

34 Organization Hierarchy
AROBAC07 Model Organization Hierarchy (OH) Assets (A) aorg atype Organizations PO UO Role Hierarchy (RH) User-(Role, Org) Assignment (UA) Permission-Role Assignment (PA) Asset Types Users (U) (Roles, Orgs) Regular Roles ARRA Operations . user Red: addition to the regular ROBAC. active_role-orgs Admin Roles Permissions (P) Sessions (S) Constraints

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); 35

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); 36

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 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

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 38

39 UROA07 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 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)). 40

41 UROA07 Example

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

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 ) ROBACM models allow an asset to be related to more than one organization and/or an asset can belong to more than one asset type while the rule to make access decision remains the same as that in ROBAC regular models. If a new security policy, “Schools in the same district can view each other’s reports”, is need to be added in the aforementioned B2B example, we can easily model this new requirement by using ROBAC1M. The aorg(a) in ROBAC1M will include all organizations within the same district that organization o , to which asset a is originally related, is in.

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 When applying the aforementioned two secure interoperation principles in the context of ROBAC, the autonomy principle means that security setup for some collaboration policy among different organizations should not reduce the original permissions a user has within the user’s original organization and the security principle means that the collaboration setup among the different organizations should not increase the original permissions a user has in the user’s original organization.

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 We can see that the want-to-be-shared assets are related to both the original organization and the newly created virtual organization. This is why we need to use manifold ROBAC to model secure collaboration; therefore, users with the same role but in different participating organizations can share assets without violating the two secure interoperation principles.

47 Secure Collaboration Example
Assets a21 a12 a22 a11 a23 a13 @PT1 @PT2 @VPT12 – Project Team – Project Team 2; @VPT12 – Virtual Project Team a11, a12,a13 are assets related a21, a22, a23 are assets related

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) = }, i = 1, 2, 3; aorg(a2i) = }, i = 1, 2, 3; atype(aij ) = { X }  At, i = 1, 2; j = 1, 2, 3; op  Op, ( (op, X), ENG )  PA; Before collaboration: can access asset a11, a12, a13 but not a21, a22, a23 can access asset a21, a22, a23 but not a11, a12, a13 Collaboration grant: Create a virtual project During collaboration: can access asset a11, a12, a13, a21, a23 can access asset a21, a22, a23, a13 Collaboration Revoke: Remove and all related association After Collaboration: System returns to its original status automatically The only changes we made in the original ROBACM are to add a virtual organization in the organization hierarchy and allow the shared assets to also relate to the newly created virtual organization. There is no change to the other elements of ROABCM. There is no role-mapping, role-translation, or role-exporting needed in our approach. The required shared assets a13, a21, and a23, which are related to the virtual organization, are automatically shared by the users with or membership. Who has the authority to grant and setup collaboration? Who has the authority to setup shared resources for collaboration? Which role can associate with the virtual organization? Who should manage the newly created assets during the collaboration?

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. ROBAC is more intuitive and succinct than many existing RBAC extensions when it is used for situations involving a large number of organizational units It inherits RBAC’s beneficial features and provides a way to restrict access control within specified organizational units without introducing too much administrative burden on access control systems. AROBAC07 is a ROBAC approach to perform administrative work on ROBAC systems AROBAC07 scales up well and better than using existing role based administrative models for situations involving a large number of organizational units.

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. Finally, two ROBAC variants, manifold ROBAC (ROBACM) and pseudo ROBAC (ROBACP), are introduced. The usefulness of manifold ROBAC is demonstrated in secure collaboration. ROBAC models are well positioned to handle secure collaboration problems due to its built-in organization hierarchy. We show that using manifold ROBAC in secure collaboration is simpler and cleaner than most existing RBAC based approaches for cross-domain collaboration. The usefulness of pseudo ROBAC is shown in a case study for a web based on-demand movie service. We show that using pseudo ROBAC usually results in less number of rules than Rule Based RABC for applications involving many similar organizations.

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. Finally, two ROBAC variants, manifold ROBAC (ROBACM) and pseudo ROBAC (ROBACP), are introduced. The usefulness of manifold ROBAC is demonstrated in secure collaboration. ROBAC models are well positioned to handle secure collaboration problems due to its built-in organization hierarchy. We show that using manifold ROBAC in secure collaboration is simpler and cleaner than most existing RBAC based approaches for cross-domain collaboration. The usefulness of pseudo ROBAC is shown in a case study for a web based on-demand movie service. We show that using pseudo ROBAC usually results in less number of rules than Rule Based RABC for applications involving many similar organizations.

53 Thank You Questions?


Download ppt "A PhD Dissertation Defense Zhixiong "Jim" Zhang"

Similar presentations


Ads by Google