Transcript Role-Based Access Control

Role-Based Access Control
Prof. Ravi Sandhu
George Mason University and
NSD Security
SACMAT 2003
ACCESS CONTROL MODELS

DAC: Discretionary Access Control, 1971




MAC: Mandatory Access Control, 1971





Source: Academic theoreticians (including myself)
No real implementations
CW: Clark-Wilson, 1987



Source: By product of MAC
Still around in niche situations, mostly US military funded
CPM: Controlled Propagation Models, 1976


Source: Military and national security
Not widely used even by military
DTE: Domain and Type Enforcement, 1985


Source: Academia and research laboratories
Predominant in commercial systems in pre-RBAC era, in many flavors
Continues to influence modern RBAC systems
Source: Commercial sector
No real implementations
RBAC: Role-based Access Control, 1992



Source: Commercial sector
Becoming dominant
Needs additional work to keep it viable
© Ravi Sandhu 2003
2
ACCESS CONTROL MODELS
RBAC
Role-based
Policy neutral
DAC
Identity based
owner controlled
© Ravi Sandhu 2003
MAC
Lattice based
label controlled
3
THE OM-AM WAY
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2003
A
s
s
u
r
a
n
c
e
4
OM-AM AND ROLE-BASED ACCESS
CONTROL (RBAC)
What?
Policy neutral
RBAC96
user-pull, server-pull, etc.
certificates, tickets, PACs, etc.
How?
© Ravi Sandhu 2003
A
s
s
u
r
a
n
c
e
5
The RBAC96 Model
ROLE-BASED ACCESS
CONTROL (RBAC)
A
user’s permissions are determined
by the user’s roles
 rather
than identity or clearance
 roles can encode arbitrary attributes
 multi-faceted
 ranges
from very simple to very
sophisticated
© Ravi Sandhu 2003
7
WHAT IS THE POLICY IN RBAC?
 RBAC
is a framework to help in
articulating policy
 The main point of RBAC is to
facilitate security management
© Ravi Sandhu 2003
8
RBAC SECURITY
PRINCIPLES
 least
privilege
 separation of duties
 separation of administration and
access
 abstract operations
© Ravi Sandhu 2003
9
RBAC96
IEEE Computer Feb. 1996
 Policy
neutral
 can be configured to do MAC
 roles
 can
be configured to do DAC
 roles
© Ravi Sandhu 2003
simulate clearances (ESORICS 96)
simulate identity (RBAC98)
10
WHAT IS RBAC?
 multidimensional
 open
ended
 ranges from simple to sophisticated
© Ravi Sandhu 2003
11
RBAC CONUNDRUM
 turn
on all roles all the time
 turn on one role only at a time
 turn on a user-specified subset of
roles
© Ravi Sandhu 2003
12
RBAC96 FAMILY OF
MODELS
RBAC3
ROLE HIERARCHIES +
CONSTRAINTS
RBAC1
ROLE
HIERARCHIES
RBAC2
CONSTRAINTS
RBAC0
BASIC RBAC
© Ravi Sandhu 2003
13
RBAC0
USER-ROLE
ASSIGNMENT
USERS
ROLES
...
© Ravi Sandhu 2003
PERMISSION-ROLE
ASSIGNMENT
PERMISSIONS
SESSIONS
14
PERMISSIONS
 Primitive
 read,
write, append, execute
 Abstract
 credit,
© Ravi Sandhu 2003
permissions
permissions
debit, inquiry
15
PERMISSIONS
 System
permissions
 Auditor
 Object
permissions
 read,
write, append, execute, credit,
debit, inquiry
© Ravi Sandhu 2003
16
PERMISSIONS
 Permissions
are positive
 No negative permissions or denials
 negative
permissions and denials can
be handled by constraints
 No

© Ravi Sandhu 2003
duties or obligations
outside scope of access control
17
ROLES AS POLICY
A
role brings together
a
collection of users and
 a collection of permissions
 These
collections will vary over time
A
role has significance and meaning
beyond the particular users and
permissions brought together at any
moment
© Ravi Sandhu 2003
18
ROLES VERSUS GROUPS
 Groups
a
A
are often defined as
collection of users
role is
a
collection of users and
 a collection of permissions
 Some
a
© Ravi Sandhu 2003
authors define role as
collection of permissions
19
USERS
 Users
are
 human
beings or
 other active agents
 Each
individual should be known as
exactly one user
© Ravi Sandhu 2003
20
USER-ROLE ASSIGNMENT
A
user can be a member of many
roles
 Each role can have many users as
members
© Ravi Sandhu 2003
21
SESSIONS
A
user can invoke multiple sessions
 In each session a user can invoke
any subset of roles that the user is a
member of
© Ravi Sandhu 2003
22
PERMISSION-ROLE ASSIGNMENT
A
permission can be assigned to
many roles
 Each role can have many
permissions
© Ravi Sandhu 2003
23
MANAGEMENT OF RBAC
 Option
1:
USER-ROLE-ASSIGNMENT and
PERMISSION-ROLE ASSIGNMENT
can be changed only by the chief
security officer
 Option 2:
Use RBAC to manage RBAC
© Ravi Sandhu 2003
24
RBAC1
ROLE HIERARCHIES
USER-ROLE
ASSIGNMENT
USERS
ROLES
...
© Ravi Sandhu 2003
PERMISSION-ROLE
ASSIGNMENT
PERMISSIONS
SESSIONS
25
HIERARCHICAL ROLES
Primary-Care
Physician
Specialist
Physician
Physician
Health-Care Provider
© Ravi Sandhu 2003
26
HIERARCHICAL ROLES
Supervising
Engineer
Hardware
Engineer
Software
Engineer
Engineer
© Ravi Sandhu 2003
27
PRIVATE ROLES
Hardware
Engineer’
Supervising
Engineer
Hardware
Engineer
Software
Engineer’
Software
Engineer
Engineer
© Ravi Sandhu 2003
28
EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Production 1
(P1)
Project Lead 2
(PL2)
Quality 1
(Q1)
Production 2
(P2)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2003
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
PROJECT 2
29
EXAMPLE ROLE HIERARCHY
Project Lead 1
(PL1)
Production 1
(P1)
Project Lead 2
(PL2)
Quality 1
(Q1)
Production 2
(P2)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2003
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
PROJECT 2
30
EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Production 1
(P1)
Quality 1
(Q1)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2003
Project Lead 2
(PL2)
Production 2
(P2)
Quality 2
(Q2)
Engineer 2
(E2)
PROJECT 2
31
EXAMPLE ROLE HIERARCHY
Project Lead 1
(PL1)
Production 1
(P1)
Quality 1
(Q1)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2003
Project Lead 2
(PL2)
Production 2
(P2)
Quality 2
(Q2)
Engineer 2
(E2)
PROJECT 2
32
RBAC3
ROLE HIERARCHIES
USER-ROLE
ASSIGNMENT
USERS
ROLES
...
© Ravi Sandhu 2003
PERMISSIONS-ROLE
ASSIGNMENT
SESSIONS
PERMISSIONS
CONSTRAINTS
33
CONSTRAINTS
 Mutually
Exclusive Roles
 Static
Exclusion: The same individual
can never hold both roles
 Dynamic Exclusion: The same
individual can never hold both roles in
the same context
© Ravi Sandhu 2003
34
CONSTRAINTS
 Mutually
Exclusive Permissions
 Static
Exclusion: The same role should
never be assigned both permissions
 Dynamic Exclusion: The same role can
never hold both permissions in the
same context
© Ravi Sandhu 2003
35
CONSTRAINTS
 Cardinality
Constraints on User-Role
Assignment
 At
most k users can belong to the role
 At least k users must belong to the role
 Exactly k users must belong to the role
© Ravi Sandhu 2003
36
CONSTRAINTS
 Cardinality
Constraints on
Permissions-Role Assignment
 At
most k roles can get the permission
 At least k roles must get the permission
 Exactly k roles must get the permission
© Ravi Sandhu 2003
37
RBAC-MAC-DAC
RBAC96
ROLE HIERARCHIES
USER-ROLE
ASSIGNMENT
USERS
ROLES
...
© Ravi Sandhu 2003
PERMISSIONS-ROLE
ASSIGNMENT
PERMISSIONS
SESSIONS
CONSTRAINTS
39
LBAC: LIBERAL *-PROPERTY
H
M1
-
-
+
Read
Write
M2
L
© Ravi Sandhu 2003
+
40
RBAC96: LIBERAL *-PROPERTY
+
HR
M1R
M2R
M1W
-
LR
Read
© Ravi Sandhu 2003
LW
M2W
HW
Write
41
RBAC96: LIBERAL *-PROPERTY
 xR, user has clearance x
user  LW, independent of clearance
 Need constraints
 user
 xR iff session  xW
 read can be assigned only to xR roles
 write can be assigned only to xW roles
 (O,read) assigned to xR iff
(O,write) assigned to xW
 session
© Ravi Sandhu 2003
42
DAC IN RBAC
 Each
user can create discretionary
roles for assigning grantable
permissions
 For true DAC need grantable
permissions for each object owned
by the user
© Ravi Sandhu 2003
43
Administrative RBAC
ARBAC97
SCALE AND RATE OF
CHANGE
 roles:
100s or 1000s
 users: 1000s or 10,000s or more
 Frequent changes to
 user-role
assignment
 permission-role assignment
 Less
frequent changes for
 role
© Ravi Sandhu 2003
hierarchy
45
ADMINISTRATIVE RBAC
ROLES
USERS
CANMANAGE
...
ADMIN
ROLES
© Ravi Sandhu 2003
PERMISSIONS
ADMIN
PERMISSIONS
46
ARBAC97 DECENTRALIZES
 user-role
assignment (URA97)
 permission-role assignment (PRA97)
 role-role hierarchy
•
•
•
groups or user-only roles (extend URA97)
abilities or permission-only roles (extend PRA97)
UP-roles or user-and-permission roles (RRA97)
© Ravi Sandhu 2003
47
ADMINISTRATIVE RBAC
RBAC3
RBAC1
RBAC2
RBAC0
© Ravi Sandhu 2003
ARBAC3
ARBAC1
ARBAC2
ARBAC0
48
EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Production 1
(P1)
Project Lead 2
(PL2)
Quality 1
(Q1)
Production 2
(P2)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2003
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
PROJECT 2
49
EXAMPLE ADMINISTRATIVE
ROLE HIERARCHY
Senior Security Officer (SSO)
Department Security Officer (DSO)
Project Security
Officer 1 (PSO1)
© Ravi Sandhu 2003
Project Security
Officer 2 (PSO2)
50
URA97 GRANT MODEL:
can-assign
ARole
PSO1
PSO2
DSO
SSO
SSO
© Ravi Sandhu 2003
Prereq Role
ED
ED
ED
E
ED
Role Range
[E1,PL1)
[E2,PL2)
(ED,DIR)
[ED,ED]
(ED,DIR]
51
URA97 GRANT MODEL :
can-assign
ARole
PSO1
PSO1
PSO1
PSO2
PSO2
PSO2
© Ravi Sandhu 2003
Prereq Cond
ED
ED & ¬ P1
ED & ¬ Q1
ED
ED & ¬ P2
ED & ¬ Q2
Role Range
[E1,E1]
[Q1,Q1]
[P1,P1]
[E2,E2]
[Q2,Q2]
[P2,P2]
52
URA97 GRANT MODEL
 “redundant”
assignments to senior
and junior roles
 are
allowed
 are useful
© Ravi Sandhu 2003
53
URA97 REVOKE MODEL
 WEAK
REVOCATION
 revokes
explicit membership in a role
 independent of who did the assignment
© Ravi Sandhu 2003
54
URA97 REVOKE MODEL
 STRONG
 revokes
REVOCATION
explicit membership in a role and its
seniors
 authorized only if corresponding weak
revokes are authorized
 alternatives
•
•
all-or-nothing
revoke within range
© Ravi Sandhu 2003
55
URA97 REVOKE MODEL :
can-revoke
ARole
PSO1
PSO2
DSO
SSO
© Ravi Sandhu 2003
Role Range
[E1,PL1)
[E2,PL2)
(ED,DIR)
[ED,DIR]
56
PERMISSION-ROLE
ASSIGNMENT
 dual
of user-role assignment
 can-assign-permission
can-revoke-permission
 weak revoke
strong revoke (propagates down)
© Ravi Sandhu 2003
57
PERMISSION-ROLE ASSIGNMENT
CAN-ASSIGN-PERMISSION
ARole
PSO1
PSO2
DSO
SSO
SSO
© Ravi Sandhu 2003
Prereq Cond
PL1
PL2
E1  E2
PL1  PL2
ED
Role Range
[E1,PL1)
[E2,PL2)
[ED,ED]
[ED,ED]
[E,E]
58
PERMISSION-ROLE ASSIGNMENT
CAN-REVOKE-PERMISSION
ARole
PSO1
PSO2
DSO
SSO
© Ravi Sandhu 2003
Role Range
[E1,PL1]
[E2,PL2]
(ED,DIR)
[ED,DIR]
59
ARBAC97 DECENTRALIZES
 user-role
assignment (URA97)
 permission-role assignment (PRA97)
 role-role hierarchy
•
•
•
groups or user-only roles (extend URA97)
abilities or permission-only roles (extend PRA97)
UP-roles or user-and-permission roles (RRA97)
© Ravi Sandhu 2003
60
Range Definitions
Rang
e
Create Range
Encap. Range
Authority
Range
© Ravi Sandhu 2003
61
RBAC Architectures and Mechanisms
OM-AM AND ROLE-BASED ACCESS
CONTROL (RBAC)
What?
Objective neutral
RBAC96, ARBAC97, etc.
user-pull, server-pull, etc.
certificates, tickets, PACs, etc.
How?
© Ravi Sandhu 2003
A
s
s
u
r
a
n
c
e
63
SERVER MIRROR
Client
Server
User-role
Authorization
Server
© Ravi Sandhu 2003
64
SERVER-PULL
Client
Server
User-role
Authorization
Server
© Ravi Sandhu 2003
65
USER-PULL
Client
Server
User-role
Authorization
Server
© Ravi Sandhu 2003
66
PROXY-BASED
Client
Proxy
Server
Server
User-role
Authorization
Server
© Ravi Sandhu 2003
67
THE OM-AM WAY
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2003
A
s
s
u
r
a
n
c
e
68