No Slide Title
Download
Report
Transcript No Slide Title
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
ACCESS CONTROL
Also
called
Authorization
Entitlement
Different
from
Authentication
Typically
requires authentication as a
prerequisite
© Ravi Sandhu 2001
2
AUTHORIZATION, TRUST AND RISK
Information
security is fundamentally
about managing
authorization
and
trust
so as to manage risk
We don’t know how to do this
© Ravi Sandhu 2001
3
ACCESS CONTROL
PRINCIPLES
Least
privilege
Separation of duties
Abstract permissions
Decentralized administration
Keep it simple stupid (KISS)
© Ravi Sandhu 2001
4
ACCESS CONTROL MODELS
RBAC
Role-based
access control
DAC
Discretionary
access control
© Ravi Sandhu 2001
MAC
Mandatory
access control
5
ACCESS CONTROL MODELS
RBAC
Role-based
Policy configured
DAC
Identity based
Owner controlled
© Ravi Sandhu 2001
MAC
Lattice based
Policy controlled
6
WHY DO WE NEED MODELS
Separate the questions of
Provide a framework for managing complexity
What
How
Complex authorization
Simple authorization
Allow us to guarantee and understand policy
Prove safety theorems
Capture policy in constraints
© Ravi Sandhu 2001
7
WHY DO WE NEED MODELS
Separate the questions of
Provide a framework for managing complexity
What
How
Complex authorization
Simple authorization
Allow us to guarantee and understand policy
Prove safety theorems
Capture policy in constraints
© Ravi Sandhu 2001
8
WHY DO WE NEED MODELS
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2001
A
s
s
u
r
a
n
c
e
9
ADMINISTRATIVE RBAC
USERS
© Ravi Sandhu 2001
ROLES
PERMISSIONS
ADMIN
ROLES
ADMIN
PERMISSIONS
...
10
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 2001
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
PROJECT 2
11
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 2001
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
PROJECT 2
12
EXAMPLE ROLE HIERARCHY
Director (DIR)
Project Lead 1
(PL1)
Production 1
(P1)
Quality 1
(Q1)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2001
Project Lead 2
(PL2)
Production 2
(P2)
Quality 2
(Q2)
Engineer 2
(E2)
PROJECT 2
13
EXAMPLE ROLE HIERARCHY
Project Lead 1
(PL1)
Production 1
(P1)
Quality 1
(Q1)
Engineer 1
(E1)
PROJECT 1
© Ravi Sandhu 2001
Project Lead 2
(PL2)
Production 2
(P2)
Quality 2
(Q2)
Engineer 2
(E2)
PROJECT 2
14
WHY DO WE NEED MODELS
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2001
A
s
s
u
r
a
n
c
e
15
ACCESS-CONTROL ARCHITECTURE
SERVER-PULL
Client
Authorization
Server
© Ravi Sandhu 2001
Server
Authentication
Server
16
ACCESS-CONTROL ARCHITECTURE
USER-PULL
Client
Authorization
Server
© Ravi Sandhu 2001
Server
Authentication
Server
17
ACCESS-CONTROL ARCHITECTURE
PROXY-BASED
Client
Proxy
Authentication
Server
© Ravi Sandhu 2001
Server
Authorization
Server
18
WHY DO WE NEED MODELS
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2001
A
s
s
u
r
a
n
c
e
19
ACCESS-CONTROL MECHANISM
SECURE COOKIES IN USER-PULL ARCHITECTURE
© Ravi Sandhu 2001
20
ACCESS-CONTROL MECHANISM
X.509 CERTIFICATES
X.509
certificates can be used in
User-pull
architecture
Server-pull architecture
Secure
© Ravi Sandhu 2001
cookies inherently user pull
21
WHY DO WE NEED MODELS
Separate the questions of
Provide a framework for managing complexity
What
How
Complex authorization
Simple authorization
Allow us to guarantee and understand policy
Prove safety theorems
Capture policy in constraints
© Ravi Sandhu 2001
22
WHY DO WE NEED MODELS
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2001
A
s
s
u
r
a
n
c
e
23
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
© Ravi Sandhu 2001
24
COMPLEX AUTHORIZATION
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 2001
Quality 2
(Q2)
Engineer 2
(E2)
Engineering Department (ED)
Employee (E)
PROJECT 2
25
COMPLEX AUTHORIZATION
Senior Security Officer (SSO)
Department Security Officer (DSO)
Project Security
Officer 1 (PSO1)
© Ravi Sandhu 2001
Project Security
Officer 2 (PSO2)
26
SIMPLE AUTHORIZATION
Internal User
Senior Administrator
External User
Junior Administrator
© Ravi Sandhu 2001
27
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
© Ravi Sandhu 2001
28
WHY DO WE NEED MODELS
Separate the questions of
Provide a framework for managing complexity
What
How
Complex authorization
Simple authorization
Allow us to guarantee and understand policy
Prove safety theorems
Capture policy in constraints
© Ravi Sandhu 2001
29
WHY DO WE NEED MODELS
What?
Objectives
Model
Architecture
Mechanism
How?
© Ravi Sandhu 2001
A
s
s
u
r
a
n
c
e
30
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
© Ravi Sandhu 2001
31
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
© Ravi Sandhu 2001
32
PERMISSION-CENTRIC
SEPARATION OF DUTIES
SSOD-CP
|permissions(roles(OE(U)))
Variations
OE(CP)| 1
of SSOD-CP
|permissions(OE(R)) OE(CP)| 1
SSOD-CP
© Ravi Sandhu 2001
33
CONSTRAINTS
CHARACTERIZATION
PROHIBITION
OBLIGATION
CONSTRAINTS
© Ravi Sandhu 2001
34
SIMPLE PROHIBITION
CONSTRAINTS
Type 1
Type 2
expr 1
expr or expr 0
Type 3
© Ravi Sandhu 2001
expr1expr2
35
SIMPLE OBLIGATION
CONSTRAINTS
Type 1
Type 2
Set X Set Y
Type 3
obligation constraints obligation constraints
expr 0 or expr 0
Type 4
expr 1
© Ravi Sandhu 2001
expr 1 expr 1 expr 0
36
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?
© Ravi Sandhu 2001
37
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
© Ravi Sandhu 2001
38