1. Role-Based Access Control George Mason University and
Prof. Ravi Sandhu
George Mason University and
NSD Security
SACMAT 2003

2. ACCESS CONTROL MODELS DAC: Discretionary Access Control, 1971
Source: Academia and research laboratories
Predominant in commercial systems in pre-RBAC era, in many flavors
Continues to influence modern RBAC systems
MAC: Mandatory Access Control, 1971
Source: Military and national security
Not widely used even by military
DTE: Domain and Type Enforcement, 1985
Source: By product of MAC
Still around in niche situations, mostly US military funded
CPM: Controlled Propagation Models, 1976
Source: Academic theoreticians (including myself)
No real implementations
CW: Clark-Wilson, 1987
Source: Commercial sector
RBAC: Role-based Access Control, 1992
Becoming dominant
Needs additional work to keep it viable

3. ACCESS CONTROL MODELS RBAC Role-based Policy neutral DAC
Identity based
owner controlled
MAC
Lattice based
label controlled

4. THE OM-AM WAY A What? s u Objectives r Model a n Architecture c
Mechanism
How?

5. OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)u r a n c e
What?
How?
Policy neutral
RBAC96
user-pull, server-pull, etc.
certificates, tickets, PACs, etc.

6. The RBAC96 Model

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

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

9. RBAC SECURITY PRINCIPLES
least privilege
separation of duties
separation of administration and access
abstract operations

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

11. WHAT IS RBAC? multidimensional open ended
ranges from simple to sophisticated

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

13. RBAC96 FAMILY OF MODELS RBAC3 ROLE HIERARCHIES + CONSTRAINTS RBAC1
BASIC RBAC

14. RBAC0 ... ROLES USER-ROLE ASSIGNMENT PERMISSION-ROLE USERS PERMISSIONS
SESSIONS
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice

15. PERMISSIONS Primitive permissions Abstract permissions
read, write, append, execute
Abstract permissions
credit, debit, inquiry
RBAC should be a flexible concept that can accommodate all of these

16. PERMISSIONS System permissions Object permissions Auditor
read, write, append, execute, credit, debit, inquiry
RBAC should be a flexible concept that can accommodate all of these

17. 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
RBAC should be a flexible concept that can accommodate all of these

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

19. ROLES VERSUS GROUPS Groups are often defined as A role is
a collection of users
A role is
a collection of users and
a collection of permissions
Some authors define role as
Several mechanisms can be used should not be
surprising, or
disturbing
Just as
a car can have front-wheel or rear-wheel drive, or
a RISC or CISC CPU can execute the same program
Some mechanisms are better suited than others
is the key issue in this paper

20. USERS Users are Each individual should be known as exactly one user
human beings or
other active agents
Each individual should be known as exactly one user
RBAC should be a flexible concept that can accommodate all of these

21. USER-ROLE ASSIGNMENT A user can be a member of many roles
Each role can have many users as members
RBAC should be a flexible concept that can accommodate all of these

22. 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
RBAC should be a flexible concept that can accommodate all of these

23. PERMISSION-ROLE ASSIGNMENT
A permission can be assigned to many roles
Each role can have many permissions
RBAC should be a flexible concept that can accommodate all of these

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

25. RBAC1 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSION-ROLE
USERS
ROLES
PERMISSIONS
...
SESSIONS
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice

26. HIERARCHICAL ROLES Primary-Care Physician Specialist Physician
Health-Care Provider

27. HIERARCHICAL ROLES
Engineer
Hardware
Software
Supervising

28. PRIVATE ROLES
Engineer
Hardware
Software
Supervising
Engineer’

29. EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Project Lead 2
(PL2)
Production 1
(P1)
Quality 1
(Q1)
Production 2
(P2)
Quality 2
(Q2)
Engineer 1
(E1)
Engineer 2
(E2)
PROJECT 1
Engineering Department (ED)
PROJECT 2
Employee (E)

30. EXAMPLE ROLE HIERARCHY
Project Lead 1
(PL1)
Project Lead 2
(PL2)
Production 1
(P1)
Quality 1
(Q1)
Production 2
(P2)
Quality 2
(Q2)
Engineer 1
(E1)
Engineer 2
(E2)
PROJECT 1
Engineering Department (ED)
PROJECT 2
Employee (E)

31. EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Project Lead 2
(PL2)
Production 1
(P1)
Quality 1
(Q1)
Production 2
(P2)
Quality 2
(Q2)
Engineer 1
(E1)
Engineer 2
(E2)
PROJECT 1
PROJECT 2

32. EXAMPLE ROLE HIERARCHY
Project Lead 1
(PL1)
Project Lead 2
(PL2)
Production 1
(P1)
Quality 1
(Q1)
Production 2
(P2)
Quality 2
(Q2)
Engineer 1
(E1)
Engineer 2
(E2)
PROJECT 1
PROJECT 2

33. RBAC3 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE
USERS
ROLES
PERMISSIONS
...
SESSIONS
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice
CONSTRAINTS

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

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

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

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

38. RBAC-MAC-DAC

39. RBAC96 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE
USERS
ROLES
PERMISSIONS
...
SESSIONS
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice
CONSTRAINTS

40. LBAC: LIBERAL *-PROPERTY+ - H L M1 M2 - +
Read
Write

41. RBAC96: LIBERAL *-PROPERTY+ HR LR
M1R
M2R LW HW
M1W
M2W -
Read Write

42. RBAC96: LIBERAL *-PROPERTY
user  xR, user has clearance x
user  LW, independent of clearance
Need constraints
session  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

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

44. Administrative RBAC
ARBAC97

45. 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 hierarchy

46. ADMINISTRATIVE RBAC ... ROLES PERMISSIONS USERS CAN- MANAGE ADMIN
This is a somewhat busy slide
It shows a bird’s eye view of RBAC
There are many details that need to be debated and filled in
Some of these will be discussed in the subsequent panel
For our purpose the bird’s eye view will suffice

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

48. ADMINISTRATIVE RBAC RBAC2 RBAC1 RBAC0 RBAC3 ARBAC2 ARBAC1 ARBAC0

49. EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Project Lead 2
(PL2)
Production 1
(P1)
Quality 1
(Q1)
Production 2
(P2)
Quality 2
(Q2)
Engineer 1
(E1)
Engineer 2
(E2)
PROJECT 1
Engineering Department (ED)
PROJECT 2
Employee (E)

50. EXAMPLE ADMINISTRATIVE ROLE HIERARCHY
Senior Security Officer (SSO)
Department Security Officer (DSO)
Project Security
Officer 1 (PSO1)
Project Security
Officer 2 (PSO2)

51. 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]

52. URA97 GRANT MODEL : can-assign
ARole Prereq Cond Role Range
PSO1 ED [E1,E1]
PSO1 ED & ¬ P1 [Q1,Q1]
PSO1 ED & ¬ Q1 [P1,P1]
PSO2 ED [E2,E2]
PSO2 ED & ¬ P2 [Q2,Q2]
PSO2 ED & ¬ Q2 [P2,P2]

53. URA97 GRANT MODEL “redundant” assignments to senior and junior roles
are allowed
are useful

54. URA97 REVOKE MODEL WEAK REVOCATION
revokes explicit membership in a role
independent of who did the assignment

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

56. URA97 REVOKE MODEL : can-revoke
ARole Role Range
PSO1 [E1,PL1)
PSO2 [E2,PL2)
DSO (ED,DIR)
SSO [ED,DIR]

57. PERMISSION-ROLE ASSIGNMENT
dual of user-role assignment
can-assign-permission
can-revoke-permission
weak revoke
strong revoke (propagates down)

58. 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]

59. PERMISSION-ROLE ASSIGNMENT CAN-REVOKE-PERMISSION
ARole Role Range
PSO1 [E1,PL1]
PSO2 [E2,PL2]
DSO (ED,DIR)
SSO [ED,DIR]

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

61. Range Definitions
Range
Create Range
Encap. Range
Authority
Range

62. RBAC Architectures and Mechanisms

63. OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)u r a n c e
What?
How?
Objective neutral
RBAC96, ARBAC97, etc.
user-pull, server-pull, etc.
certificates, tickets, PACs, etc.

64. SERVER MIRROR
Client
Server
User-role
Authorization
Server

65. SERVER-PULL
Client
Server
User-role
Authorization
Server

66. USER-PULL
Client
Server
User-role
Authorization
Server

67. PROXY-BASED
Client
Proxy
Server
Server
User-role
Authorization
Server

68. THE OM-AM WAY A What? s u Objectives r Model a n Architecture c
Mechanism
How?