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

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
1
Presentation Outline
•
•
•
•
•
•
•
•
•
Introduction
Motivating Examples
Problem Summary
ROBAC Models
AROBAC07 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
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)
3
Traditional RBAC Model (RBAC96 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 (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
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)
• ……
6
Motivating Examples
• B2B Example
– Web-based report delivery System
• B2C Example
– Online subscription-based tutoring system
7
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?
8
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
9
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
10
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
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: ROBAC0, ROBAC1,
ROBAC2, and ROBAC3
14
ROBAC0
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)
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
16
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_roleorgs(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
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.
18
ROBAC1
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)
•
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_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
ROBAC2
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
ROBAC3
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)
• 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
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
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
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
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: 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
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
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
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
30
organization
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
31
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
32
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)
33
AROBAC07 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
Regular Roles
(PA)
Operations
ARRA
active_role-orgs
Asset Types
Assignment
Permissions
(P)
Admin Roles
Sessions
(S)
Constraints
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
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
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
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
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 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
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
UROA07 Example
41
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
42
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 )
43
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
44
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
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
a21
a12
a11
a22
a23
a13
@PT1
@PT2
@VPT12
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.
47
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
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 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.
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 [PST91];
• Integrate general constraints in ROBAC;
• Detail the implementation perspective of ROBACM based
secure collaboration schema;
• ……
51
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.
52
Thank You
• Questions?
53