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

Architecture

Mechanism

Assurance

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

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

RBAC96 FAMILY OF MODELS

RBAC0BASIC RBAC

RBAC3ROLE HIERARCHIES +

CONSTRAINTS

RBAC1ROLE

HIERARCHIES

RBAC2CONSTRAINTS

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

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

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

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

USER-ROLEASSIGNMENT

PERMISSIONS-ROLEASSIGNMENT

USERS PERMISSIONS

... SESSIONS

ROLE HIERARCHIES

CONSTRAINTS

LBAC: LIBERAL *-PROPERTY

Read Write- +

RBAC96: LIBERAL *-PROPERTY

M1R M2R

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

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

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

Create Range

Encap. Range

AuthorityRange

RBAC Architectures and Mechanisms

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

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

Architecture

Mechanism

Assurance

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

Documents

Dr. Sandhu Career Investigation

CMS Issues. Background – RAL Infrastructure TM Nsd Xrd- mgr TM Nsd Xrd- mgr TM Rhd stagerd TGW Rhd stagerd TGW Cupv Vmgr Vdqm nsd Cupv Vmgr Vdqm nsd Cupv

SACMAT 03© Mohammad Al-Kahtani1 Induced Role Hierarchies with Attribute-Based RBAC Mohammad A. Al-Kahtani Ravi Sandhu George Mason University NSD Security,

Towards Usage Control Models: Beyond Traditional Access Control 7 th SACMAT, June 3, 2002 Jaehong Park and Ravi Sandhu Laboratory for Information Security

NSD BCS RMS

Computer Programming (UTA003) (Jasonpreet Sandhu)

Kim sandhu

NSD Prospectus 2012

NSD ERP® SYSTEM PP-HR...Our products, NSD ERP SYSTEM, NSD Inventory System, NSD Monitor Management System (MOM System), NSD Car and Transport Management System (CMS), NSD Business

1 Rethinking Password Strategies Ravi Sandhu Chief Scientist sandhu@nsdsecurity.com 703 283 3484 sandhu@nsdsecurity.com

NSD ERP SYSTEM - Human Resources - Training Management. NSD ERP SYSTEM - Human Resources - Training Management. NSD ERP SYSTEM HUMAN RESOURCES MODULE Training

1 SACMAT 2002 © Oh and Sandhu 2002 A Model for Role Administration Using Organization Structure Sejong Oh Ravi Sandhu * George Mason University

1 Privacy and Access Control: How are These Two Concepts Related? Prof. Ravi Sandhu Executive Director and Endowed Chair SACMAT Panel June 3, 2015 ravi.sandhu@utsa.edu

Welcome! NSD Vibrant Disciples

Solar System Finished Harjit Sandhu

Annual Report 2014 - NSD

© Ravi Sandhu HRU and TAM Ravi Sandhu Laboratory for Information Security Technology George Mason University sandhu@gmu.edu

Received by NSD/FARA Registration Unit … FORM NSD-3 Received by NSD/FARA Registration Unit 01/02/2015 1:41:45 PM Revised 03/14 . Received by NSD/FARA Registration Unit 01/02/2015

NISN Services Document (NSD)

Tajinder Sandhu