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. 2 © Ravi Sandhu 2001 ACCESS CONTROL Also called Authorization Entitlement Different from Authentication Typically requires authentication as a prerequisite

3. 3 © Ravi Sandhu 2001 AUTHORIZATION, TRUST AND RISK Information security is fundamentally about managing authorization and trust so as to manage risk We dont know how to do this

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

5. 5 © Ravi Sandhu 2001 ACCESS CONTROL MODELS RBAC Role-based access control DAC Discretionary access control MAC Mandatory access control

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

7. 7 © Ravi Sandhu 2001 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. 8 © Ravi Sandhu 2001 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. 9 © Ravi Sandhu 2001 WHY DO WE NEED MODELS Objectives Model Architecture Mechanism What? How? AssuranceAssurance

10. 10 © Ravi Sandhu 2001 ADMINISTRATIVE RBAC ROLES USERS PERMISSIONS... ADMIN ROLES ADMIN PERMISSIONS

11. 11 © Ravi Sandhu 2001 EXAMPLE ROLE HIERARCHY Employee (E) Engineering Department (ED) Project Lead 1 (PL1) Engineer 1 (E1) Production 1 (P1) Quality 1 (Q1) Director (DIR) Project Lead 2 (PL2) Engineer 2 (E2) Production 2 (P2) Quality 2 (Q2) PROJECT 2PROJECT 1

12. 12 © Ravi Sandhu 2001 EXAMPLE ROLE HIERARCHY Employee (E) Engineering Department (ED) Project Lead 1 (PL1) Engineer 1 (E1) Production 1 (P1) Quality 1 (Q1) Project Lead 2 (PL2) Engineer 2 (E2) Production 2 (P2) Quality 2 (Q2) PROJECT 2PROJECT 1

13. 13 © Ravi Sandhu 2001 EXAMPLE ROLE HIERARCHY Project Lead 1 (PL1) Engineer 1 (E1) Production 1 (P1) Quality 1 (Q1) Director (DIR) Project Lead 2 (PL2) Engineer 2 (E2) Production 2 (P2) Quality 2 (Q2) PROJECT 2PROJECT 1

14. 14 © Ravi Sandhu 2001 EXAMPLE ROLE HIERARCHY Project Lead 1 (PL1) Engineer 1 (E1) Production 1 (P1) Quality 1 (Q1) Project Lead 2 (PL2) Engineer 2 (E2) Production 2 (P2) Quality 2 (Q2) PROJECT 2PROJECT 1

15. 15 © Ravi Sandhu 2001 WHY DO WE NEED MODELS Objectives Model Architecture Mechanism What? How? AssuranceAssurance

16. 16 © Ravi Sandhu 2001 ACCESS-CONTROL ARCHITECTURE SERVER-PULL ClientServer Authorization Server Authentication Server

17. 17 © Ravi Sandhu 2001 ACCESS-CONTROL ARCHITECTURE USER-PULL ClientServer Authorization Server Authentication Server

18. 18 © Ravi Sandhu 2001 ACCESS-CONTROL ARCHITECTURE PROXY-BASED ClientServerProxy Authentication Server Authorization Server

19. 19 © Ravi Sandhu 2001 WHY DO WE NEED MODELS Objectives Model Architecture Mechanism What? How? AssuranceAssurance

20. 20 © Ravi Sandhu 2001 ACCESS-CONTROL MECHANISM SECURE COOKIES IN USER-PULL ARCHITECTURE

21. 21 © Ravi Sandhu 2001 ACCESS-CONTROL MECHANISM X.509 CERTIFICATES X.509 certificates can be used in User-pull architecture Server-pull architecture Secure cookies inherently user pull

22. 22 © Ravi Sandhu 2001 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. 23 © Ravi Sandhu 2001 WHY DO WE NEED MODELS Objectives Model Architecture Mechanism What? How? AssuranceAssurance

24. 24 © Ravi Sandhu 2001 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. 25 © Ravi Sandhu 2001 COMPLEX AUTHORIZATION Employee (E) Engineering Department (ED) Project Lead 1 (PL1) Engineer 1 (E1) Production 1 (P1) Quality 1 (Q1) Director (DIR) Project Lead 2 (PL2) Engineer 2 (E2) Production 2 (P2) Quality 2 (Q2) PROJECT 2PROJECT 1

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

27. 27 © Ravi Sandhu 2001 SIMPLE AUTHORIZATION External User Internal User Senior Administrator Junior Administrator

28. 28 © Ravi Sandhu 2001 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. 29 © Ravi Sandhu 2001 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. 30 © Ravi Sandhu 2001 WHY DO WE NEED MODELS Objectives Model Architecture Mechanism What? How? AssuranceAssurance

31. 31 © Ravi Sandhu 2001 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. 32 © Ravi Sandhu 2001 ROLE-CENTRIC SEPARATION OF DUTIES Static SOD : Conflicting roles cannot have common users U = {u 1,u 2,…u n }, R = {r 1,r 2,…r n }, CR = {cr 1,cr 2 } : cr 1 = {r 1,r 2,r 3 }, cr 2 = {r a,r b,r c } |roles(OE(U)) OE(CR)| 1

33. 33 © Ravi Sandhu 2001 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. 34 © Ravi Sandhu 2001 CONSTRAINTS CHARACTERIZATION CONSTRAINTS PROHIBITIONOBLIGATION

35. 35 © Ravi Sandhu 2001 SIMPLE PROHIBITION CONSTRAINTS Type 1 expr 1 Type 2 expr or expr 0 Type 3 expr1 expr2

36. 36 © Ravi Sandhu 2001 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 n expr 1 expr 1 expr 0

37. 37 © Ravi Sandhu 2001 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. 38 © Ravi Sandhu 2001 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