Future%20Directions%20in

1
Future Directions in Role-Based Access Control
Models
Ravi Sandhu Co-Founder and Chief
Scientist SingleSignOn.Net Professor of
Information Technology and Engineering George
Mason University
2
ACCESS CONTROL

• Also called
• Authorization
• Entitlement
• Different from
• Authentication
• Typically requires authentication as a
  prerequisite

3
AUTHORIZATION, TRUST AND RISK

• Information security is fundamentally about
  managing
• authorization and
• trust
• so as to manage risk
• We dont know how to do this

4
ACCESS CONTROL PRINCIPLES

• Least privilege
• Separation of duties
• Abstract permissions
• Decentralized administration
• Keep it simple stupid (KISS)

5
ACCESS CONTROL MODELS
RBAC Role-based access control
DAC Discretionary access control
MAC Mandatory access control
6
ACCESS CONTROL MODELS
RBAC Role-based Policy configured
DAC Identity based Owner controlled
MAC Lattice based Policy controlled
7
WHY DO WE NEED MODELS

• Separate the questions of
• What
• How
• Provide a framework for managing complexity
• Complex authorization
• Simple authorization
• Allow us to guarantee and understand policy
• Prove safety theorems
• Capture policy in constraints

8
WHY DO WE NEED MODELS

• Separate the questions of
• What
• How
• Provide a framework for managing complexity
• Complex authorization
• Simple authorization
• Allow us to guarantee and understand policy
• Prove safety theorems
• Capture policy in constraints

9
WHY DO WE NEED MODELS
A s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

How?
10
ADMINISTRATIVE RBAC
ROLES
PERMISSIONS
USERS
ADMIN ROLES
ADMIN PERMISSIONS
11
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)
12
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)
13
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
14
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
15
WHY DO WE NEED MODELS
A s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

How?
16
ACCESS-CONTROL ARCHITECTURESERVER-PULL
Client
Server
Authorization Server
Authentication Server
17
ACCESS-CONTROL ARCHITECTUREUSER-PULL
Client
Server
Authorization Server
Authentication Server
18
ACCESS-CONTROL ARCHITECTUREPROXY-BASED
Client
Server
Proxy
Authentication Server
Authorization Server
19
WHY DO WE NEED MODELS
A s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

How?
20
ACCESS-CONTROL MECHANISMSECURE COOKIES IN
USER-PULL ARCHITECTURE
21
ACCESS-CONTROL MECHANISMX.509 CERTIFICATES

• X.509 certificates can be used in
• User-pull architecture
• Server-pull architecture
• Secure cookies inherently user pull

22
WHY DO WE NEED MODELS

• Separate the questions of
• What
• How
• Provide a framework for managing complexity
• Complex authorization
• Simple authorization
• Allow us to guarantee and understand policy
• Prove safety theorems
• Capture policy in constraints

23
WHY DO WE NEED MODELS
A s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

How?
24
COMPLEX VERSUS SIMPLE AUTHORIZATION

• Complex authorization
• Many roles hundreds, thousands
• Dynamic policy and complex administration
• Simple authorization
• Few roles tens
• Static policy and simple administration

25
COMPLEX AUTHORIZATION
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)
26
COMPLEX AUTHORIZATION
Senior Security Officer (SSO)
Department Security Officer (DSO)
Project Security Officer 1 (PSO1)
Project Security Officer 2 (PSO2)
27
SIMPLE AUTHORIZATION
Senior Administrator
Internal User
External User
Junior Administrator
28
COMPLEX AUTHORIZATION VERSUS COMPLEX PERMISSIONS

• A consumer has access to only his own account and
  to no other account
• A branch manager has access to accounts of
  customers at his branch but no accounts at any
  other branch

29
WHY DO WE NEED MODELS

• Separate the questions of
• What
• How
• Provide a framework for managing complexity
• Complex authorization
• Simple authorization
• Allow us to guarantee and understand policy
• Prove safety theorems
• Capture policy in constraints

30
WHY DO WE NEED MODELS
A s s u r a n c e
What?

• Objectives
• Model
• Architecture
• Mechanism

How?
31
RBAC POLICY

• Policy in RBAC is determined by
• Hierarchies
• Constraints
• MAC and DAC can be configured in RBAC by suitable
  design of hierarchies and constraints

32
ROLE-CENTRIC SEPARATION OF DUTIES

• Static SOD
• Conflicting roles cannot have common users
• U u1,u2,un , R r1,r2,rn,
• CR cr1,cr2 cr1 r1,r2,r3 , cr2
  ra,rb,rc
• roles(OE(U)) ? OE(CR) ?1

33
PERMISSION-CENTRIC SEPARATION OF DUTIES

• SSOD-CP
• permissions(roles(OE(U))) ? OE(CP) ?1
• Variations of SSOD-CP
• SSOD-CP ?
• permissions(OE(R)) ? OE(CP) ?1

34
CONSTRAINTS CHARACTERIZATION
PROHIBITION
OBLIGATION
CONSTRAINTS
35
SIMPLE PROHIBITION CONSTRAINTS

• Type 1
• ?expr ?? 1
• Type 2
• expr ? ? or ?expr?? 0
• Type 3
• ?expr1???expr2?

36
SIMPLE OBLIGATION CONSTRAINTS

• Type 1
• expr ? 0 or ?expr?? 0
• Type 2
• Set X ? Set Y
• Type 3
• obligation constraints ? obligation constraints
• Type 4
• ?expr ? ? 1
• ?expr ? ? 1 ? ?expr ?? 1 ? ?expr?? 0

37
LOOKING AHEAD

• Do we need more models or should we focus on
  understanding how to make better use of existing
  models?
• How do we know we have a good model?

38
LOOKING AHEAD

• Engineering systems with complex authorizations
• Deeper understanding of simple constraints and
  policy that can serve as building blocks
• How to implement a model with different trust and
  performance tradeoffs