© 2004 ravi sandhu role-based access control prof. ravi sandhu laboratory for information security...
TRANSCRIPT
© 2004 Ravi Sandhuwww.list.gmu.edu
Role-Based Access Control
Prof. Ravi SandhuLaboratory for Information Security Technology
George Mason University
www.list.gmu.edu
© 2004 Ravi Sandhuwww.list.gmu.edu
Access Control Models:A perspective
3
© 2004 Ravi Sandhuwww.list.gmu.edu
Access Matrix Model (Lampson 1971)
U r w
V
F
Subjects
Objects (and Subjects)
r w
G
r
rights
4
© 2004 Ravi Sandhuwww.list.gmu.edu
Access Matrix Model
• Separates authentication from authorization• Rights are persistent
These items have come into question in recent times, but that is a topic for another talk.
• Separates model from implementation• Policy versus mechanism
This separation continues to be valuable and will be discussed and refined later in this talk.
5
© 2004 Ravi Sandhuwww.list.gmu.edu
MAC, DAC and RBAC
• For 25 years (1971-96) access control was divided into• Mandatory Access Control (MAC)
• Discretionary Access Control (DAC)
• Since the early-mid 1990’s Role-Based Access Control (RBAC) has become a dominant force• RBAC subsumes MAC and DAC
• RBAC is not the “final” answer BUT is a critical piece of the “final” answer
6
© 2004 Ravi Sandhuwww.list.gmu.edu
Mandatory Access Control (MAC)
TS
S
C
U
InformationFlow
Dominance
Lattice ofsecuritylabels
Rights are determined by security labels (Bell-LaPadula 1971)
7
© 2004 Ravi Sandhuwww.list.gmu.edu
Mandatory Access Control (MAC)
U r w
V
F
Subjects
Objects (and Subjects)
r w
G
r
security label of F must dominate or equal security label of G
8
© 2004 Ravi Sandhuwww.list.gmu.edu
Discretionary Access Control (DAC)
• The owner of a resource determines access to that resource• The owner is often the creator of the resource
• Fails to distinguish read from copy• This distinction has re-emerged recently under the
name Dissemination Control (DCON)
9
© 2004 Ravi Sandhuwww.list.gmu.edu
Discretionary Access Control (DAC)
U r w
V
F
Subjects
Objects (and Subjects)
r w
G
r
10
© 2004 Ravi Sandhuwww.list.gmu.edu
Discretionary Access Control (DAC)
U r wown
V
F
Subjects
Objects (and Subjects)
r wown
G
r
Rights are determined by the owners
11
© 2004 Ravi Sandhuwww.list.gmu.edu
Beyond DAC and MAC
• Many attempts were made• Domain-Type enforcement (Boebert-Kain 1985)• Clark-Wilson (1987)• Chinese Walls (Brewer-Nash 1989)• Harrison-Ruzzo-Ullman (1976)• Schematic Protection Model (Sandhu 1985)• Typed Access Matrix Model (Sandhu 1992)• …………………
• RBAC solves this problem
© 2004 Ravi Sandhuwww.list.gmu.edu
Role-Based Access Control:The RBAC96 Model
• Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, “Role-Based Access Control Models.” IEEE Computer, Volume 29, Number 2, February 1996, pages 38-47.
13
© 2004 Ravi Sandhuwww.list.gmu.edu
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
14
© 2004 Ravi Sandhuwww.list.gmu.edu
Central concept of RBAC
ROLES
USER-ROLEASSIGNMENT
PERMISSION-ROLEASSIGNMENT
USERS PERMISSIONS
15
© 2004 Ravi Sandhuwww.list.gmu.edu
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
16
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC SECURITY PRINCIPLES
• least privilege
• separation of duties
• separation of administration and access
• abstract operations
17
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC96 IEEE Computer Feb. 1996
• Policy neutral
• can be configured to do MAC• roles simulate clearances (ESORICS 96)
• can be configured to do DAC• roles simulate identity (RBAC98)
18
© 2004 Ravi Sandhuwww.list.gmu.edu
WHAT IS RBAC?
• multidimensional
• open ended
• ranges from simple to sophisticated
19
© 2004 Ravi Sandhuwww.list.gmu.edu
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
20
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC96 FAMILY OF MODELS
RBAC0BASIC RBAC
RBAC3ROLE HIERARCHIES +
CONSTRAINTS
RBAC1ROLE
HIERARCHIES
RBAC2CONSTRAINTS
21
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC0
ROLES
USER-ROLEASSIGNMENT
PERMISSION-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
22
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSIONS
• Primitive permissions• read, write, append, execute
• Abstract permissions• credit, debit, inquiry
23
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSIONS
• System permissions• Auditor
• Object permissions• read, write, append, execute, credit, debit, inquiry
24
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSIONS
• Permissions are positive
• No negative permissions or denials• negative permissions and denials can be handled
by constraints
• No duties or obligations• outside scope of access control
25
© 2004 Ravi Sandhuwww.list.gmu.edu
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
26
© 2004 Ravi Sandhuwww.list.gmu.edu
ROLES VERSUS GROUPS
• Groups are often defined as• a collection of users
• A role is• a collection of users and• a collection of permissions
• Some authors define role as • a collection of permissions
27
© 2004 Ravi Sandhuwww.list.gmu.edu
USERS
• Users are• human beings or• other active agents
• Each individual should be known as exactly one user
28
© 2004 Ravi Sandhuwww.list.gmu.edu
USER-ROLE ASSIGNMENT
• A user can be a member of many roles
• Each role can have many users as members
29
© 2004 Ravi Sandhuwww.list.gmu.edu
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
30
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSION-ROLE ASSIGNMENT
• A permission can be assigned to many roles
• Each role can have many permissions
31
© 2004 Ravi Sandhuwww.list.gmu.edu
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
32
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC1
ROLES
USER-ROLEASSIGNMENT
PERMISSION-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
33
© 2004 Ravi Sandhuwww.list.gmu.edu
HIERARCHICAL ROLES
Health-Care Provider
Physician
Primary-CarePhysician
SpecialistPhysician
34
© 2004 Ravi Sandhuwww.list.gmu.edu
HIERARCHICAL ROLES
Engineer
HardwareEngineer
SoftwareEngineer
SupervisingEngineer
35
© 2004 Ravi Sandhuwww.list.gmu.edu
PRIVATE ROLES
Engineer
HardwareEngineer
SoftwareEngineer
SupervisingEngineer
HardwareEngineer’
SoftwareEngineer’
36
© 2004 Ravi Sandhuwww.list.gmu.edu
EXAMPLE ROLE HIERARCHY
Employee (E)
Engineering Department (ED)
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Director (DIR)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
PROJECT 2PROJECT 1
37
© 2004 Ravi Sandhuwww.list.gmu.edu
EXAMPLE ROLE HIERARCHY
Employee (E)
Engineering Department (ED)
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
PROJECT 2PROJECT 1
38
© 2004 Ravi Sandhuwww.list.gmu.edu
EXAMPLE ROLE HIERARCHY
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Director (DIR)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
PROJECT 2PROJECT 1
39
© 2004 Ravi Sandhuwww.list.gmu.edu
EXAMPLE ROLE HIERARCHY
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
PROJECT 2PROJECT 1
40
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC3
ROLES
USER-ROLEASSIGNMENT
PERMISSIONS-ROLEASSIGNMENT
USERS PERMISSIONS
... SESSIONS
ROLE HIERARCHIES
CONSTRAINTS
41
© 2004 Ravi Sandhuwww.list.gmu.edu
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
42
© 2004 Ravi Sandhuwww.list.gmu.edu
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
43
© 2004 Ravi Sandhuwww.list.gmu.edu
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
44
© 2004 Ravi Sandhuwww.list.gmu.edu
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
© 2004 Ravi Sandhuwww.list.gmu.edu
The NIST-ANSI and (hopefully) soon-to-be ISO RBAC Standard Model
• David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn and Ramaswamy Chandramouli. “Proposed NIST Standard for Role-Based Access Control.” ACM Transactions on Information and System Security, Volume 4, Number 3, August 2001, pages 224-274.
46
© 2004 Ravi Sandhuwww.list.gmu.edu
The NIST-ANSI-ISO RBAC Model
• Adds much needed detail and consensus agreement to the RBAC96 model and other contemporary models
• Focuses on areas where consensus agreement exists and commercial implementations have been demonstrated• Leaves many important areas for future work
• Eventual goal is much more ambitious• Test suite for conformance testing
47
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC96 FAMILY OF MODELS
RBAC0BASIC RBAC
RBAC3ROLE HIERARCHIES +
CONSTRAINTS
RBAC1ROLE
HIERARCHIES
RBAC2CONSTRAINTS
48
© 2004 Ravi Sandhuwww.list.gmu.edu
The NIST-ANSI-ISO RBAC Model
49
© 2004 Ravi Sandhuwww.list.gmu.edu
The NIST-ANSI-ISO RBAC Model
• Additional details• Administrative Functions• Supporting System Functions• Review Functions
50
© 2004 Ravi Sandhuwww.list.gmu.edu
Core RBAC
51
© 2004 Ravi Sandhuwww.list.gmu.edu
Core RBAC: Administrative Functions
• AddUser• DeleteUser• AddRole• DeleteRole• AssignUser• DeassignUser• Grant-Permission• Revoke-Permission
52
© 2004 Ravi Sandhuwww.list.gmu.edu
Core RBAC: Supporting System Functions
• CreateSession
• AddActiveRole
• DropActiveRole
• CheckAccess
53
© 2004 Ravi Sandhuwww.list.gmu.edu
Core RBAC: Review Functions
• Required• AssignedUsers• AssignedRoles
• Optional• RolePermissions• UserPermissions• SessionRoles• SessionPermissions• RoleOperationsOnObject• SessionOperationsOnObject
Role-permission review is optional
Role-user review is required
54
© 2004 Ravi Sandhuwww.list.gmu.edu
Hierarchical RBAC
55
© 2004 Ravi Sandhuwww.list.gmu.edu
Limited Hierarchies
56
© 2004 Ravi Sandhuwww.list.gmu.edu
Limited Hierarchies
57
© 2004 Ravi Sandhuwww.list.gmu.edu
General Hierarchies
58
© 2004 Ravi Sandhuwww.list.gmu.edu
Inheritance versus Activation Hierarchy
59
© 2004 Ravi Sandhuwww.list.gmu.edu
Inheritance versus Activation Hierarchy
• Inheritance hierarchy• Activating Director Role also activates all junior roles (by
inheritance of permissions)• Violates least privilege
• Activation hierarchy• Activating Director Role does not activate junior roles
(there is no inheritance of permissions)• Junior roles must be explicitly activated• Preserves least privilege but is less automated
60
© 2004 Ravi Sandhuwww.list.gmu.edu
Constrained RBAC: Static Separation of Duties
61
© 2004 Ravi Sandhuwww.list.gmu.edu
Constrained RBAC: Dynamic Separation of Duties
© 2004 Ravi Sandhuwww.list.gmu.edu
MAC and DAC in RBAC
• Sylvia Osborn, Ravi Sandhu and Qamar Munawer. “Configuring Role-Based Access Control to Enforce Mandatory and Discretionary Access Control Policies.” ACM Transactions on Information and System Security, Volume 3, Number 2, May 2000, pages 85-106.
63
© 2004 Ravi Sandhuwww.list.gmu.edu
MAC
H
L
M1 M2
Read Write- +
+ -
64
© 2004 Ravi Sandhuwww.list.gmu.edu
MAC in RBAC96
HR
LR
M1R M2R
LW
HW
M1W M2W
Read Write-
+
65
© 2004 Ravi Sandhuwww.list.gmu.edu
MAC in RBAC96• user xR, user has clearance x• user LW, independent of clearance• Need constraints
• session xR iff session xW• in a session exactly one read role must be activated, and this
cannot be changed• 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
66
© 2004 Ravi Sandhuwww.list.gmu.edu
DAC in RBAC96
• Construction is more complex
• Requires multiple roles for every object
• Revocation• Grant-dependent revocation is harder to handle• Grant-independent revocation is easier to handle
67
© 2004 Ravi Sandhuwww.list.gmu.edu
MAC and DAC in the NIST-ANSI-ISO Model
• RBAC96 constructions use cardinality constraints in addition to Static and Dynamic separation of duties
• These constructions are not applicable to NIST-ANSI-ISO RBAC model
• Can NIST-ANSI-ISO RBAC model do MAC and DAC?• With extensions: yes
• Without extensions: probably not
© 2004 Ravi Sandhuwww.list.gmu.edu
Administrative RBAC: ARBAC97
• Ravi Sandhu, Venkata Bhamidipati and Qamar Munawer. “The ARBAC97 Model for Role-Based Administration of Roles.” ACM Transactions on Information and System Security, Volume 2, Number 1, February 1999, pages 105-135.
© 2004 Ravi Sandhuwww.list.gmu.edu
EXAMPLE ROLE HIERARCHY
Employee (E)
Engineering Department (ED)
Project Lead 1(PL1)
Engineer 1(E1)
Production 1(P1)
Quality 1(Q1)
Director (DIR)
Project Lead 2(PL2)
Engineer 2(E2)
Production 2(P2)
Quality 2(Q2)
PROJECT 2PROJECT 1
© 2004 Ravi Sandhuwww.list.gmu.edu
EXAMPLE ADMINISTRATIVE ROLE HIERARCHY
Senior Security Officer (SSO)
Department Security Officer (DSO)
Project SecurityOfficer 1 (PSO1)
Project SecurityOfficer 2 (PSO2)
71
© 2004 Ravi Sandhuwww.list.gmu.edu
URA97 GRANT MODEL: can-assign
ARole Prereq Role Role Range
PSO1 ED [E1,PL1)
PSO2 ED [E2,PL2)
DSO ED (ED,DIR)
SSO E [ED,ED]
SSO ED (ED,DIR]
72
© 2004 Ravi Sandhuwww.list.gmu.edu
URA97 GRANT MODEL
• “redundant” assignments to senior and junior roles• are allowed• are useful
73
© 2004 Ravi Sandhuwww.list.gmu.edu
URA97 REVOKE MODEL
WEAK REVOCATION• revokes explicit membership in a role• independent of who did the assignment
74
© 2004 Ravi Sandhuwww.list.gmu.edu
URA97 REVOKE MODEL
STRONG REVOCATION• revokes explicit membership in a role and its seniors• authorized only if corresponding weak revokes are
authorized• alternatives
– all-or-nothing
– revoke within range
75
© 2004 Ravi Sandhuwww.list.gmu.edu
URA97 REVOKE MODEL : can-revoke
ARole Role Range
PSO1 [E1,PL1)
PSO2 [E2,PL2)
DSO (ED,DIR)
SSO [ED,DIR]
76
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSION-ROLE ASSIGNMENT
• dual of user-role assignment• can-assign-permission• can-revoke-permission• weak revoke• strong revoke (propagates down)
77
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSION-ROLE ASSIGNMENT CAN-ASSIGN-PERMISSION
ARole Prereq Cond Role Range
PSO1 PL1 [E1,PL1)
PSO2 PL2 [E2,PL2)
DSO E1 E2 [ED,ED]
SSO PL1 PL2 [ED,ED]
SSO ED [E,E]
78
© 2004 Ravi Sandhuwww.list.gmu.edu
PERMISSION-ROLE ASSIGNMENT CAN-REVOKE-PERMISSION
ARole Role Range
PSO1 [E1,PL1]
PSO2 [E2,PL2]
DSO (ED,DIR)
SSO [ED,DIR]
© 2004 Ravi Sandhuwww.list.gmu.edu
OM-AM and RBAC
80
© 2004 Ravi Sandhuwww.list.gmu.edu
THE OM-AM WAY
Objectives
Model
Architecture
Mechanism
What?
How?
Assurance
81
© 2004 Ravi Sandhuwww.list.gmu.edu
LAYERS AND LAYERS
• Multics rings• Layered abstractions• Waterfall model• Network protocol stacks• Napolean layers• RoFi layers• OM-AM• etcetera
82
© 2004 Ravi Sandhuwww.list.gmu.edu
OM-AM AND MANDATORY ACCESS CONTROL (MAC)
What?
How?
No information leakage
Lattices (Bell-LaPadula)
Security kernel
Security labels
Assurance
83
© 2004 Ravi Sandhuwww.list.gmu.edu
OM-AM AND DISCRETIONARY ACCESS CONTROL (DAC)
What?
How?
Owner-based discretion
numerous
numerous
ACLs, Capabilities, etc
Assurance
84
© 2004 Ravi Sandhuwww.list.gmu.edu
OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)
What?
How?
Objective neutral
RBAC96, ARBAC97, etc.
user-pull, server-pull, etc.
certificates, tickets, PACs, etc.
Assurance
85
© 2004 Ravi Sandhuwww.list.gmu.edu
Server-Pull Architecture
Client Server
User-roleAuthorization
Server
86
© 2004 Ravi Sandhuwww.list.gmu.edu
User-Pull Architecture
Client Server
User-roleAuthorization
Server
87
© 2004 Ravi Sandhuwww.list.gmu.edu
Proxy-Based Architecture
Client ServerProxyServer
User-roleAuthorization
Server
88
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC Mechanisms
• RBAC can be implemented using• Secure cookies: user-pull architecture• X.509 certificates: user-pull or server-pull
architectures
© 2004 Ravi Sandhuwww.list.gmu.edu
Other RBAC Research and Results
90
© 2004 Ravi Sandhuwww.list.gmu.edu
RBAC Research (dates are approximate)
• The early NIST model: Ferraiolo et al 1992 onwards• Role-Graph Model: Osborn et al 1994 onwards• OASIS model and architecture: Moody et al 1994 onwards• Trust Management: Herzberg, Li, Winsborough, et al 1996 onwards• Temporal RBAC: Bertino et al 1998 onwards• Constraint languages: Ahn and Sandhu, 2000• Delegation in RBAC: Barka, Sandhu, Ahn et al 2000 onwards• RBAC and workflow systems: Atluri, Sandhu, Ahn, Park et al 1998 onwards• RBAC administration: Kern, Sandhu, Oh, Moffett et al 1998 onwards• RBAC engineering: Thomsen, Kern, Epstein, Sandhu et al 2000 onwards• Context-aware RBAC: Covington et al, 2000 onwards• Rule-based RBAC: Al-Khatani and Sandhu, 2002 onwards• ………………….
© 2004 Ravi Sandhuwww.list.gmu.edu
Ongoing and Future Work in RBAC
92
© 2004 Ravi Sandhuwww.list.gmu.edu
Research Challenges
• Automated RBAC• RBAC engineering• Formal models for RBAC• Analysis of RBAC policies• Integration with attribute-based access control• RBAC in pervasive and ad hoc environments• Cross-domain RBAC• ………….