Scalable Role

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

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
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)
Sessions
Constraints
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
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)

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 subordinates reports
• A school principle can access some types of
  his/her schools reports but it cannot access
  other types of his/her schools reports which can
  be access by the schools 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 childrens
  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_1s 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

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

15
ROBAC0
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
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-or
  ganization assignment relation
• to be continued

16
17
ROBAC0 Formal Definition (contd)

• 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

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 as type and
  asset a is related to organization o.

19
ROBAC1
Note Changes From RBAC Blue - modified
elements Red - new elements
Assets (A)
Organization Hierarchy (OH)
atype
aorg
Organizations
Permission-Role Assignment (PA)
Role Hierarchy (RH)
User-(Role, Org) Assignment (UA)
Asset Types
Users (U)
(Roles, Orgs)
Roles
Operations
? ? . . ?
user
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
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
active_role-orgs
Permissions (P)
Sessions (S)
Constraints
22
ROBAC3
Note Changes From RBAC Blue - modified
elements Red - new elements
Assets (A)
Organization Hierarchy (OH)
atype
aorg
Organizations
Permission-Role Assignment (PA)
Role Hierarchy (RH)
User-(Role, Org) Assignment (UA)
Asset Types
Users (U)
(Roles, Orgs)
Roles
Operations
? ? . . ?
user
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

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 gt n
  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 gt 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.
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

28
29
Comparison with Classic RBAC RcRBAC O ?
1 ( RcROBAC -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 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 N?M
Role-org pairs administration N/A ROA07 (be covered in AROBAC07)
Org administration N/A OOA07 (be covered in AROBAC07)
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 roles permissions and
  the organization units 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

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

34
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
Operations
ARRA
? ? . . ?
user
active_role-orgs
Permissions (P)
Admin Roles
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
  (PSO, _at_PT1) is a security administrator in
  project team 1
• may_manage_user(PSO, u, (PE, _at_PT1), ?(QE, ?)) is
  true if user u is affiliated with project team 1
  (_at_PT1) and u is not a QE inside the project team
  1
• The user with active role-org pair (PSO, _at_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, _at_PT1) and (QE, _at_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

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 )

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
Assets
a21
a12
a22
a11
a23
a13
_at_PT1
_at_PT2
_at_VPT12
Legend _at_PT1 Project Team 1 _at_PT2 Project
Team 2 _at_VPT12 Virtual Project
Team under _at_PT1 and _at_PT2 a11,
a12,a13 are assets related to _at_PT1 a21, a22, a23
are assets related to _at_PT2.
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) _at_PT1 , i 1, 2, 3
• aorg(a2i) _at_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, _at_PT1) can access asset a11, a12, a13 but
  not a21, a22, a23
• (ENG, _at_PT2) can access asset a21, a22, a23 but
  not a11, a12, a13
• Collaboration grant
• Create a virtual project team _at_VPT12 under _at_PT1
  and _at_PT2
• During collaboration
• (ENG, _at_PT1) can access asset a11, a12, a13, a21,
  a23
• (ENG, _at_PT2) can access asset a21, a22, a23, a13
• Collaboration Revoke
• Remove the _at_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?