Role-Based Access Control

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

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

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

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

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

6. The RBAC96 Model

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

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

9. RBAC SECURITY PRINCIPLES • least privilege • separation of duties • separation of administration and access • abstract operations

10. 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)

11. WHAT IS RBAC? • multidimensional • open ended • ranges from simple to sophisticated

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

13. RBAC1 ROLE HIERARCHIES RBAC2 CONSTRAINTS RBAC96 FAMILY OF MODELS RBAC3 ROLE HIERARCHIES + CONSTRAINTS RBAC0 BASIC RBAC

14. USER-ROLE ASSIGNMENT PERMISSION-ROLE ASSIGNMENT USERS ROLES PERMISSIONS ... SESSIONS RBAC0

15. PERMISSIONS • Primitive permissions • read, write, append, execute • Abstract permissions • credit, debit, inquiry

16. PERMISSIONS • System permissions • Auditor • Object permissions • read, write, append, execute, credit, debit, inquiry

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

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

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

20. USERS • Users are • human beings or • other active agents • Each individual should be known as exactly one user

21. USER-ROLE ASSIGNMENT • A user can be a member of many roles • Each role can have many users as members

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

23. PERMISSION-ROLE ASSIGNMENT • A permission can be assigned to many roles • Each role can have many permissions

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

25. ... RBAC1 ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSION-ROLE ASSIGNMENT USERS ROLES PERMISSIONS SESSIONS

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

27. Supervising Engineer Hardware Engineer Software Engineer Engineer HIERARCHICAL ROLES

28. Hardware Engineer’ Software Engineer’ Supervising Engineer Hardware Engineer Software Engineer Engineer PRIVATE ROLES

29. 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 1 PROJECT 2 Employee (E)

30. 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 1 PROJECT 2 Employee (E)

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

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

33. ... RBAC3 ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS SESSIONS CONSTRAINTS

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

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

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

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

38. RBAC-MAC-DAC

39. ... RBAC96 ROLE HIERARCHIES USER-ROLE ASSIGNMENT PERMISSIONS-ROLE ASSIGNMENT USERS ROLES PERMISSIONS SESSIONS CONSTRAINTS

40. + - H M1 M2 - + L LBAC: LIBERAL *-PROPERTY Read Write

41. HR LW M1R M2R LR HW RBAC96: LIBERAL *-PROPERTY + M1W M2W - Read Write

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

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

44. Administrative RBAC ARBAC97

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

46. ... ADMINISTRATIVE RBAC ROLES PERMISSIONS USERS CAN- MANAGE ADMIN ROLES ADMIN PERMISSIONS

47. 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)

48. RBAC3 ARBAC3 RBAC1 RBAC2 ARBAC1 ARBAC2 RBAC0 ARBAC0 ADMINISTRATIVE RBAC

49. 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 1 PROJECT 2 Employee (E)

50. EXAMPLE ADMINISTRATIVE ROLE HIERARCHY Senior Security Officer (SSO) Department Security Officer (DSO) Project Security Officer 1 (PSO1) Project Security Officer 2 (PSO2)