Role-Based Access Control

1
Role-Based Access Control
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
• No real implementations
• RBAC Role-based Access Control, 1992
• Source Commercial sector
• Becoming dominant

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 s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

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

• A users permissions are determined by the users
  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
RBAC96IEEE 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
RBAC0 BASIC RBAC
14
RBAC0
15
PERMISSIONS

• Primitive permissions
• read, write, append, execute
• Abstract permissions
• credit, debit, inquiry

16
PERMISSIONS

• System permissions
• Auditor
• Object permissions
• read, write, append, execute, credit, debit,
  inquiry

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

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 collection of users
• A role is
• a collection of users and
• a collection of permissions
• Some authors define role as
• a collection of permissions

20
USERS

• Users are
• human beings or
• other active agents
• Each individual should be known as exactly one
  user

21
USER-ROLE ASSIGNMENT

• A user can be a member of many roles
• Each role can have many users as members

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

23
PERMISSION-ROLE ASSIGNMENT

• A permission can be assigned to many roles
• Each role can have many permissions

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 ASSIGNMENT
ROLES
USERS
PERMISSIONS
SESSIONS
26
HIERARCHICAL ROLES
Primary-Care Physician
Specialist Physician
Physician
Health-Care Provider
27
HIERARCHICAL ROLES
28
PRIVATE ROLES
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)
Engineering Department (ED)
PROJECT 2
PROJECT 1
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)
Engineering Department (ED)
PROJECT 2
PROJECT 1
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 2
PROJECT 1
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 2
PROJECT 1
33
RBAC3
ROLE HIERARCHIES
USER-ROLE ASSIGNMENT
PERMISSIONS-ROLE ASSIGNMENT
ROLES
USERS
PERMISSIONS
SESSIONS
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 ASSIGNMENT
ROLES
USERS
PERMISSIONS
SESSIONS
CONSTRAINTS
40
LBAC LIBERAL -PROPERTY
Read
Write
41
RBAC96 LIBERAL -PROPERTY

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 ROLES
ADMIN PERMISSIONS
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
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)
Engineering Department (ED)
PROJECT 2
PROJECT 1
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 MODELcan-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)
A s s u r a n c e
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
Server
Proxy Server
User-role Authorization Server
68
THE OM-AM WAY
A s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

How?