Role-Based Access Control George Mason University and Prof. Ravi Sandhu George Mason University and NSD Security SACMAT 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 RBAC: Role-based Access Control, 1992 Becoming dominant Needs additional work to keep it viable

ACCESS CONTROL MODELS RBAC Role-based Policy neutral DAC Identity based owner controlled MAC Lattice based label controlled

THE OM-AM WAY A What? s u Objectives r Model a n Architecture c Mechanism How?

OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC) u r a n c e What? How? Policy neutral RBAC96 user-pull, server-pull, etc. certificates, tickets, PACs, etc.

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

RBAC96 IEEE 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 RBAC3 ROLE HIERARCHIES + CONSTRAINTS RBAC1 BASIC RBAC

RBAC0 ... ROLES USER-ROLE ASSIGNMENT PERMISSION-ROLE USERS PERMISSIONS SESSIONS This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice

PERMISSIONS Primitive permissions Abstract permissions read, write, append, execute Abstract permissions credit, debit, inquiry RBAC should be a flexible concept that can accommodate all of these

PERMISSIONS System permissions Object permissions Auditor read, write, append, execute, credit, debit, inquiry RBAC should be a flexible concept that can accommodate all of these

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 RBAC should be a flexible concept that can accommodate all of these

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 role is a collection of users A role is a collection of users and a collection of permissions Some authors define role as Several mechanisms can be used should not be surprising, or disturbing Just as a car can have front-wheel or rear-wheel drive, or a RISC or CISC CPU can execute the same program Some mechanisms are better suited than others is the key issue in this paper

USERS Users are Each individual should be known as exactly one user human beings or other active agents Each individual should be known as exactly one user RBAC should be a flexible concept that can accommodate all of these

USER-ROLE ASSIGNMENT A user can be a member of many roles Each role can have many users as members RBAC should be a flexible concept that can accommodate all of these

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 RBAC should be a flexible concept that can accommodate all of these

PERMISSION-ROLE ASSIGNMENT A permission can be assigned to many roles Each role can have many permissions RBAC should be a flexible concept that can accommodate all of these

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 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSION-ROLE USERS ROLES PERMISSIONS ... SESSIONS This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice

HIERARCHICAL ROLES Primary-Care Physician Specialist Physician Health-Care Provider

HIERARCHICAL ROLES Engineer Hardware Software Supervising

PRIVATE ROLES Engineer Hardware Software Supervising Engineer’

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 1 Engineering Department (ED) PROJECT 2 Employee (E)

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 1 Engineering Department (ED) PROJECT 2 Employee (E)

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 1 PROJECT 2

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 1 PROJECT 2

RBAC3 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE USERS ROLES PERMISSIONS ... SESSIONS This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice 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 ... ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE USERS ROLES PERMISSIONS ... SESSIONS This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice 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 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

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

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 PERMISSIONS USERS CAN- MANAGE ADMIN This is a somewhat busy slide It shows a bird’s eye view of RBAC There are many details that need to be debated and filled in Some of these will be discussed in the subsequent panel For our purpose the bird’s eye view will suffice

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 RBAC2 RBAC1 RBAC0 RBAC3 ARBAC2 ARBAC1 ARBAC0

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 1 Engineering Department (ED) PROJECT 2 Employee (E)

EXAMPLE ADMINISTRATIVE ROLE HIERARCHY Senior Security Officer (SSO) Department Security Officer (DSO) Project Security Officer 1 (PSO1) Project Security Officer 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 Authority Range

RBAC Architectures and Mechanisms

OM-AM AND ROLE-BASED ACCESS CONTROL (RBAC) u r a n c e What? How? Objective neutral RBAC96, ARBAC97, etc. user-pull, server-pull, etc. certificates, tickets, PACs, etc.

SERVER MIRROR Client Server User-role Authorization Server

SERVER-PULL Client Server User-role Authorization Server

USER-PULL Client Server User-role Authorization Server

PROXY-BASED Client Proxy Server Server User-role Authorization Server

THE OM-AM WAY A What? s u Objectives r Model a n Architecture c Mechanism How?