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

Role-Based Access Control

Prof. Ravi Sandhu

George Mason University and

NSD Security

SACMAT 2003

2© Ravi Sandhu 2003

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 Needs additional work to keep it viable


ACCESS CONTROL MODELS

RBACRole-based

Policy neutral

DACIdentity based

owner controlled

MACLattice based

label controlled


THE OM-AM WAY

Objectives

Model

Architecture

Mechanism

What?

How?

Assurance


OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC)

What?

How?

Policy neutral

RBAC96

user-pull, server-pull, etc.

certificates, tickets, PACs, etc.

Assurance

The RBAC96 Model


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


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


RBAC SECURITY PRINCIPLES

least privilege separation of duties separation of administration and

access abstract operations


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)


WHAT IS RBAC?

multidimensional open ended ranges from simple to sophisticated


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


RBAC96 FAMILY OF MODELS

RBAC0BASIC RBAC

RBAC3ROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS


RBAC0

ROLES

USER-ROLEASSIGNMENT

PERMISSION-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS


PERMISSIONS

Primitive permissions read, write, append, execute

Abstract permissions credit, debit, inquiry


PERMISSIONS

System permissions Auditor

Object permissions read, write, append, execute, credit,

debit, inquiry


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


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


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


USERS

Users are human beings or other active agents

Each individual should be known as exactly one user


USER-ROLE ASSIGNMENT

A user can be a member of many roles

Each role can have many users as members


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


PERMISSION-ROLE ASSIGNMENT

A permission can be assigned to many roles

Each role can have many permissions


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


RBAC1

ROLES

USER-ROLEASSIGNMENT

PERMISSION-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES


HIERARCHICAL ROLES

Health-Care Provider

Physician

Primary-CarePhysician

SpecialistPhysician


HIERARCHICAL ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer


PRIVATE ROLES

Engineer

HardwareEngineer

SoftwareEngineer

SupervisingEngineer

HardwareEngineer’

SoftwareEngineer’


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



Employee (E)


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



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



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


RBAC3

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS


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


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


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


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

RBAC-MAC-DAC


RBAC96

ROLES

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS


LBAC: LIBERAL *-PROPERTY

H

L

M1 M2

Read Write- +

+ -


RBAC96: LIBERAL *-PROPERTY

HR

LR

M1R M2R

LW

HW

M1W M2W

Read Write-

+


RBAC96: LIBERAL *-PROPERTY

user xR, user has clearance xuser 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


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

Administrative RBACARBAC97


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


ADMINISTRATIVE RBAC

ROLES

USERS

PERMISSIONS

...

ADMINROLES

ADMINPERMISSIONS

CAN-MANAGE


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)


ADMINISTRATIVE RBAC

RBAC2RBAC1

RBAC0

RBAC3

ARBAC2ARBAC1

ARBAC0

ARBAC3



Employee (E)


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


EXAMPLE ADMINISTRATIVE ROLE HIERARCHY

Senior Security Officer (SSO)

Department Security Officer (DSO)

Project SecurityOfficer 1 (PSO1)

Project SecurityOfficer 2 (PSO2)


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]


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]


URA97 GRANT MODEL

“redundant” assignments to senior and junior roles are allowed are useful


URA97 REVOKE MODEL

WEAK REVOCATION revokes explicit membership in a role independent of who did the assignment


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


URA97 REVOKE MODEL :can-revoke

ARole Role Range

PSO1 [E1,PL1)

PSO2 [E2,PL2)

DSO (ED,DIR)

SSO [ED,DIR]


PERMISSION-ROLE ASSIGNMENT

dual of user-role assignment can-assign-permission

can-revoke-permission weak revoke

strong revoke (propagates down)


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]


PERMISSION-ROLE ASSIGNMENT CAN-REVOKE-PERMISSION

ARole Role Range

PSO1 [E1,PL1]

PSO2 [E2,PL2]

DSO (ED,DIR)

SSO [ED,DIR]


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)


Range Definitions

Range

Create Range

Encap. Range

AuthorityRange

RBAC Architectures and Mechanisms


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


SERVER MIRROR

Client Server

User-roleAuthorization

Server


SERVER-PULL

Client Server


Server


USER-PULL

Client Server


Server


PROXY-BASED

Client ServerProxyServer


Server


THE OM-AM WAY

Objectives

Model

Architecture

Mechanism

What?

How?

Assurance

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

Documents

rbac slide

user slide

sessions slide

permissions permissions

sophisticated slide

inquiry slide

assuranceassurance slide

member of slide