1 / 68

Role-Based Access Control

Role-Based Access Control. 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

edolie
Download Presentation

Role-Based Access Control

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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)

More Related