1 / 38

Future Directions in Role-Based Access Control Models

Explore the principles, models, and mechanisms of access control in information security, including RBAC, DAC, and MAC. Understand the need for models in managing complexity and guaranteeing policy safety.

fguillen
Download Presentation

Future Directions in Role-Based Access Control Models

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. Future Directions in Role-Based Access Control Models Ravi Sandhu Co-Founder and Chief Scientist SingleSignOn.Net & Professor of Information Technology and Engineering George Mason University

  2. ACCESS CONTROL • Also called • Authorization • Entitlement • Different from • Authentication • Typically requires authentication as a prerequisite

  3. AUTHORIZATION, TRUST AND RISK • Information security is fundamentally about managing • authorization and • trust so as to manage risk • We don’t know how to do this

  4. ACCESS CONTROL PRINCIPLES • Least privilege • Separation of duties • Abstract permissions • Decentralized administration • Keep it simple stupid (KISS)

  5. ACCESS CONTROL MODELS RBAC Role-based access control DAC Discretionary access control MAC Mandatory access control

  6. ACCESS CONTROL MODELS RBAC Role-based Policy configured DAC Identity based Owner controlled MAC Lattice based Policy controlled

  7. WHY DO WE NEED MODELS • Separate the questions of • What • How • Provide a framework for managing complexity • Complex authorization • Simple authorization • Allow us to guarantee and understand policy • Prove safety theorems • Capture policy in constraints

  8. WHY DO WE NEED MODELS • Separate the questions of • What • How • Provide a framework for managing complexity • Complex authorization • Simple authorization • Allow us to guarantee and understand policy • Prove safety theorems • Capture policy in constraints

  9. WHY DO WE NEED MODELS A s s u r a n c e What? Objectives Model Architecture Mechanism How?

  10. ... ADMINISTRATIVE RBAC ROLES PERMISSIONS USERS ADMIN ROLES ADMIN PERMISSIONS

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

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

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

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

  15. WHY DO WE NEED MODELS A s s u r a n c e What? Objectives Model Architecture Mechanism How?

  16. ACCESS-CONTROL ARCHITECTURESERVER-PULL Client Server Authorization Server Authentication Server

  17. ACCESS-CONTROL ARCHITECTUREUSER-PULL Client Server Authorization Server Authentication Server

  18. ACCESS-CONTROL ARCHITECTUREPROXY-BASED Client Proxy Server Authentication Server Authorization Server

  19. WHY DO WE NEED MODELS A s s u r a n c e What? Objectives Model Architecture Mechanism How?

  20. ACCESS-CONTROL MECHANISMSECURE COOKIES IN USER-PULL ARCHITECTURE

  21. ACCESS-CONTROL MECHANISMX.509 CERTIFICATES • X.509 certificates can be used in • User-pull architecture • Server-pull architecture • Secure cookies inherently user pull

  22. WHY DO WE NEED MODELS • Separate the questions of • What • How • Provide a framework for managing complexity • Complex authorization • Simple authorization • Allow us to guarantee and understand policy • Prove safety theorems • Capture policy in constraints

  23. WHY DO WE NEED MODELS A s s u r a n c e What? Objectives Model Architecture Mechanism How?

  24. COMPLEX VERSUS SIMPLE AUTHORIZATION • Complex authorization • Many roles: hundreds, thousands • Dynamic policy and complex administration • Simple authorization • Few roles: tens • Static policy and simple administration

  25. COMPLEX AUTHORIZATION 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)

  26. COMPLEX AUTHORIZATION Senior Security Officer (SSO) Department Security Officer (DSO) Project Security Officer 1 (PSO1) Project Security Officer 2 (PSO2)

  27. SIMPLE AUTHORIZATION Senior Administrator Internal User External User Junior Administrator

  28. COMPLEX AUTHORIZATION VERSUS COMPLEX PERMISSIONS • A consumer has access to only his own account and to no other account • A branch manager has access to accounts of customers at his branch but no accounts at any other branch

  29. WHY DO WE NEED MODELS • Separate the questions of • What • How • Provide a framework for managing complexity • Complex authorization • Simple authorization • Allow us to guarantee and understand policy • Prove safety theorems • Capture policy in constraints

  30. WHY DO WE NEED MODELS A s s u r a n c e What? Objectives Model Architecture Mechanism How?

  31. RBAC POLICY • Policy in RBAC is determined by • Hierarchies • Constraints • MAC and DAC can be configured in RBAC by suitable design of hierarchies and constraints

  32. ROLE-CENTRIC SEPARATION OF DUTIES • Static SOD : Conflicting roles cannot have common users U = {u1,u2,…un} , R = {r1,r2,…rn}, CR = {cr1,cr2} : cr1 = {r1,r2,r3} , cr2 = {ra,rb,rc} • |roles(OE(U))  OE(CR)| 1

  33. PERMISSION-CENTRIC SEPARATION OF DUTIES • SSOD-CP • |permissions(roles(OE(U)))  OE(CP)| 1 • Variations of SSOD-CP • SSOD-CP  |permissions(OE(R))  OE(CP)| 1

  34. CONSTRAINTS CHARACTERIZATION PROHIBITION OBLIGATION CONSTRAINTS

  35. SIMPLE PROHIBITION CONSTRAINTS • Type 1 • expr  1 • Type 2 • expr   or expr 0 • Type 3 • expr1expr2

  36. SIMPLE OBLIGATION CONSTRAINTS • Type 1 • expr  0 or expr 0 • Type 2 • Set X  Set Y • Type 3 • obligation constraints  obligation constraints • Type 4 • expr   1 • expr   1  expr 1  expr 0

  37. LOOKING AHEAD • Do we need more models or should we focus on understanding how to make better use of existing models? • How do we know we have a good model?

  38. LOOKING AHEAD • Engineering systems with complex authorizations • Deeper understanding of simple constraints and policy that can serve as building blocks • How to implement a model with different trust and performance tradeoffs

More Related