1 / 92

Role-Based Access Control

Role-Based Access Control. Prof. Ravi Sandhu Laboratory for Information Security Technology George Mason University www.list.gmu.edu sandhu@gmu.edu. Access Control Models: A perspective. Access Matrix Model (Lampson 1971). Objects (and Subjects). G. F. S u b j e c t s. r. r w.

mikel
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 Laboratory for Information Security Technology George Mason University www.list.gmu.edu sandhu@gmu.edu

  2. Access Control Models:A perspective

  3. Access Matrix Model (Lampson 1971) Objects (and Subjects) G F S u b j e c t s r r w U rights r w V

  4. Access Matrix Model • Separates authentication from authorization • Rights are persistent • These items have come into question in recent times, but that is a topic for another talk. • Separates model from implementation • Policy versus mechanism • This separation continues to be valuable and will be discussed and refined later in this talk.

  5. MAC, DAC and RBAC • For 25 years (1971-96) access control was divided into • Mandatory Access Control (MAC) • Discretionary Access Control (DAC) • Since the early-mid 1990’s Role-Based Access Control (RBAC) has become a dominant force • RBAC subsumes MAC and DAC • RBAC is not the “final” answer BUT is a critical piece of the “final” answer

  6. Mandatory Access Control (MAC) TS S Lattice of security labels C Information Flow Dominance U Rights are determined by security labels (Bell-LaPadula 1971)

  7. Mandatory Access Control (MAC) Objects (and Subjects) G F S u b j e c t s r r w U r w V security label of F must dominate or equal security label of G

  8. Discretionary Access Control (DAC) • The owner of a resource determines access to that resource • The owner is often the creator of the resource • Fails to distinguish read from copy • This distinction has re-emerged recently under the name Dissemination Control (DCON)

  9. Discretionary Access Control (DAC) Objects (and Subjects) G F S u b j e c t s r r w U r w V

  10. Discretionary Access Control (DAC) Objects (and Subjects) G F r w own S u b j e c t s r U r w own V Rights are determined by the owners

  11. Beyond DAC and MAC • Many attempts were made • Domain-Type enforcement (Boebert-Kain 1985) • Clark-Wilson (1987) • Chinese Walls (Brewer-Nash 1989) • Harrison-Ruzzo-Ullman (1976) • Schematic Protection Model (Sandhu 1985) • Typed Access Matrix Model (Sandhu 1992) • ………………… • RBAC solves this problem

  12. Role-Based Access Control:The RBAC96 Model Ravi Sandhu, Edward Coyne, Hal Feinstein and Charles Youman, “Role-Based Access Control Models.” IEEE Computer, Volume 29, Number 2, February 1996, pages 38-47.

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

  14. Central concept of RBAC USER-ROLE ASSIGNMENT PERMISSION-ROLE ASSIGNMENT USERS ROLES PERMISSIONS

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  34. Supervising Engineer Hardware Engineer Software Engineer Engineer HIERARCHICAL ROLES

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

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

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

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

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

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

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

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

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

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

  45. The NIST-ANSI and (hopefully) soon-to-be ISO RBAC Standard Model David F. Ferraiolo, Ravi Sandhu, Serban Gavrila, D. Richard Kuhn and Ramaswamy Chandramouli. “Proposed NIST Standard for Role-Based Access Control.” ACM Transactions on Information and System Security, Volume 4, Number 3, August 2001, pages 224-274.

  46. The NIST-ANSI-ISO RBAC Model • Adds much needed detail and consensus agreement to the RBAC96 model and other contemporary models • Focuses on areas where consensus agreement exists and commercial implementations have been demonstrated • Leaves many important areas for future work • Eventual goal is much more ambitious • Test suite for conformance testing

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

  48. The NIST-ANSI-ISO RBAC Model

  49. The NIST-ANSI-ISO RBAC Model • Additional details • Administrative Functions • Supporting System Functions • Review Functions

  50. Core RBAC

More Related