Authorization

1. Authorization Brian Garback

2. Research Issues • Authentication • who are you? • quantification of trust levels • Mobile devices • what capabilities do you have? • can wireless be as secure as wired? • Authorization • given who you are, what can you do? • how do we control privileges? • Federation • how can trust be shared? • how to cross trust domain boundaries?

3. Itinerary • History of Access Control • Role-Based AC • Context-Based AC • Context-Aware AC • Permission Based Delegation Model • Authorization Specifications • CAAC WS-Policy Implementation • XACML • SAML • Specification-Level Goals

4. Access Control History RBAC CBAC CAAC PBDM

5. Role-Based Access Control • Sandu et al. formalized Role-Based Access Control in 1996 • User U acting in role R is granted permission P • Advantage: greatly improved efficiency • Disadvantage: cannot specify fine-grained rules User Role Permission

6. Context-Based Access Control • What is “context”? • Circumstances in which an event occurs Subject Object System Name Age ID Location Type Owner Time Date CPU Load

7. Context-Based Access Control has given with • Advantage: access control is context-aware • Disadvantage: this is still a static model User Role Permission Constraints Context

8. RBAC → CBAC → CAAC • RBAC and CBAC, even with extensions, cannot meet the access requirements of modern healthcare environments • CAAC is an extension to CBAC that is consistent with implementation via web services • CAAC permits dynamic specification and dynamic enforcement of arbitrary access rules • Context implementation is separated from the main business logic of target applications.

9. Context-Aware Access Control • Presented 2004 by Juhnze Hu • Terminology: • Data Object: the smallest unit to be accessed in an application • Data Type: a group of data objects with the same attributes • Data Set: the set of all data objects • User Set: the set of potential entities that access the data objects

10. Definition 1: Context Type A context typeis defined as a property related to every participant in an application when it is running. • Context Set: a set of all context types in an application. CS = {CT1, CT2 … CTn}, 1  i  n. • Context Implementation: a function of context types defined by CI: CT1 CT2… CTn CT, n  0

11. Definition 2: Context Constraint We define a context constraint as a regular expression as follows: Context Constraint := Clause1  Clause2… Clausei Clause := Condition1 Condition2… Conditioni Condition := <CT> <OP> <VALUE> • CT is an element of CS • OP is a logical operator in set {>, , , , , =} • VALUE is a specific value of CT

12. Definition 3: Authorization Policy An authorization policy as a triple, AP = (S, P, C) where: • S: the subject in this policy, which could be a user or a role • P: the permission in this policy, which is defined as a pair <M, O>, where M is an operation mode defined in {READ, APPEND, DELETE, UPDATE} and O is a data object or data type • C: is a context constraint in this policy

13. Definition 4: Data Access We define data accessas a triple, DA = (U, P, RC) where: • U: a user in the User Set who issues this data access • P: the permission this user wants to acquire • RC: the runtime context, a set of values for every context type in the Context Set • DA (U, P, RC) is granted iff there exists an AP (S, P, C) st • U  S && • P = P && • C is evaluated as true under RC

14. CAAC Authorization Policy has given C: constraint P: permission S: user or role Clause n Clause 1  ……   ……  condition condition context type A predicate of context implementation Evaluated by

15. 2004 Security Infrastructure

16. Quick Review assigned granted • RBAC • CBAC • CAAC: • dynamic specification and dynamic enforcement of arbitrary access rules • separation of context implementation and the main business logic of target applications. User Role Permission assigned has given User Role Permission Constraints Context

17. Permission Based Delegation Model • 2003: Zhang at GMU • Given RBAC as an AC model • Delegation of authority is common • Need-to-know • Separation of duty • Rotation of sensitive job position • Delegation involves • Backup of role • Decentralization of authority • Collaboration of work

18. Delegation History • RBDM0: human → human • Delegator delegates role membership to a delegatee • RDM2000: • Role delegation in a role hierarchy and multi-step delegation • Unit of delegation is a ROLE! • PBDM • Supports role and permission level delegation

19. RBDM Shortcomings

20. Permission Based Delegation • PBDM0 Summary: • Multi-step temporal delegation • Two role types: • Regular Roles (RR) • Temporary Delegation Roles (DTR) • Multi-step delegation and revocation • Drawbacks: • No delegation limitations (risky) • No role-hierarchy

21. PBDM0 > RBDM • John creates “D1” • John assigns: • permission “change_schedule” to D1 (permission-role) • role “PE” to D1 (role-role) • John assigns Jenny to D1 (user-role)

22. Permission Based Delegation • PBDM0 Summary: • Multi-step temporal delegation • Two role types: • Regular Roles (RR) • Temporary Delegation Roles (DTR) • Multi-step delegation and revocation • Drawbacks: • No admin delegation limitations (risky) • No role-hierarchy

23. PBDM1 • Role-layers: • Regular Roles (RR) • cannot be delegated to other roles or users • Delegatable Roles (DBR) • permissions can be delegated • Delegation Roles (DTR) • created by delegatable roles • Each user has (RR, DBR) pair = RR in PBDM0 • Solves admin issue: • Administrative assignment of permissions to roles

24. PBDM1 Example • John creates a DTR “D2” • John assigns • “change schedule” to D2 from PL’ • “PE’” to D2 • John assigns Jenny to D2

25. PBDM1 Revocation • Individual user can: • Remove a user from delegatees • Remove parts from the delegation role • Admin can: • Move permissions from DBR to RR • Revoke a user from RR or DBR

26. 0 & 1 cannot support role-to-role delegation 2 does with multi-step delegation and multi-option revocation features PBDM2 > PBDM1

27. PDBM2 Overview • Four layers: • Regular roles (RR) • Fixed delegatable roles (FDBR) • owns a set of DTRs which form a role hierarchy • Temporal delegatable roles (TDBR) • has no role hierarchy • can receive permissions delegated by a FDBR (role-to-role deleg.) • Delegation roles (DTR) • owned by a FDBR • RR and FDBR: • the same as RR and DBR in PDBM1 • have role hierarchies

28. PDBM2 Rules and Example • Delegation authority handled by admin • No individual user can own a DTR or permission • Scenario: • D3 created based on PL’ and delegated to QE’’ • Create a delegation role D3 • Assign: • permission change_schedule to D3 • FDBR PE’ to D3 • Assign D3 to TDBR QE’’

29. PBDM2 Architecture • D3 created based on PL’ and delegated to QE’’ • Create a delegation role D3 • Assign: • permission change_schedule to D3 • FDBR PE’ to D3 • Assign D3 to TDBR QE’’

30. PBDM2 Revocation • Contains PBDM1’s security admin • PBDM2 has options in the role layer: • Remove pieces of permissions from a delegation role • Revoke a DTR owned by a FBDR • Remove pieces of permissions from a FBDR to a RR

31. PBDM Comparison • RBDM: • Ambiguity btw admin and delegation • PBDM: • supports role and permission level delegation • Partial revocation is also possible

32. Authorization Specifications WS-Policy XACML SAML

33. Policy Specification • Security policies must be exchangeable across domains Hospital Pharmacy Send prescription Policy response Requested License Prescription accepted

34. Policy Specification • There are several XML-based policy languages • WS-Policy (from Microsoft) • XACML (eXtensible Access Control Markup Language) • SAML (Security Assertion Markup Language) In CAAC, WS-Policy was chosen as the specification language because it is inherently supported in the Microsoft .NET framework.

35. WS-Policy Overview • Why: • To describe service requirements, preferences, and capabilities of web services • Goal: • Provide the general purpose model and syntax to describe and communicate the policies of a Web service • What: • Provides a flexible and extensible grammar for expressing the capabilities, requirements, and general characteristics of Web Services

36. CAAC Policy Specification • Our customized WS-Policy tags For any authorization policy AP = (S, P, C)

37. A Sample Policy <wsp:Policy> <wsp:AppliesTo> <wsa:EndpointReference> <wsa:DataType>PatientRecord</wsa:DataType> <wsa:AccessType>Delete</wsa:AccessType> <wsa:Permission>DeletePatientRecord</wsa:Permission> </wsa:EndpointReference> </wsp:AppliesTo> <wsse:SubjectToken wsp:Usage="Required"> <wsse:TokenType>Medical Records Staff</wsse:TokenType> </wsse:SubjectToken> <wsp:OneOrMore wsp:Usage="Required"> <wsp:All> <wsse:ContextToken wsp:Usage="wsp:GreatThan“ wsp:Preference="T(password)"> <wsse:ContextType>Trust Level</wsse:ContextType> </wsse:ContextToken> </wsp:All> </wsp:OneOrMore> </wsp:Policy>

38. XACML • OASIS standard version 1.1 (2.0 and 3.0) • Policy language • Access control decision request/response language

39. XACML - Policies • Policy Set: container of policies (local and remote) • Policy: a set of rules • Rule: a target, effect, and condition • Target: a resource, subject, and action • Effect: results of rule; “Permit” or “Deny” • Condition: Boolean; “True,” “False,” or “Indeterminate”

40. XACML – Access Control • Reconciles • Multiple policies • Multiple rules per policy • Multiple control decisions • Use a combining algorithm to combine multiple decisions into a single decision • Use standard or customized algorithms • Policy Combining Algorithms—used by PolicySet • Rule Combining Algorithms—used by Policy

41. XACML – Policy Evaluation • Obtain attributes from subject • Compare obtained attributes with attributes accepted by the policy • Evaluate conditions using standard or customized functions • E.g. The function [type]-one-and-only looks in a “bag” of attribute values and returns the single value if there is one or an error if there are zero or multiple.

42. XACML Data Flow

43. SAML assertions • An assertion is a declaration of facts about a subject • SAML has three kinds, all related to security: • Authentication • Attribute • Authorization decision • You can extend SAML to make your own kinds of assertions

44. SAML conceptual model

45. Some common information in all assertions • Issuer and issuance timestamp • Assertion ID • Subject • Name plus the security domain • Optional subject confirmation, e.g. public key • “Conditions” under which assertion is valid • SAML clients must reject assertions containing unsupported conditions • Special kind of condition: assertion validity period • Additional “advice” • E.g., to explain how the assertion was made

46. Authentication assertion • An issuing authority asserts that: • subject S • was authenticated by means M • at time T • Caution: Actually checking or revoking of credentials is not in scope for SAML! • It merely lets you link back to acts of authentication that took place previously

47. Example authentication assertion • <saml:Assertion MajorVersion=“1” MinorVersion=“0” AssertionID=“128.9.167.32.12345678” Issuer=“University of Virginia“ IssueInstant=“2003-12-03T10:02:00Z”> <saml:Conditions NotBefore=“2003-12-03T10:00:00Z” NotAfter=“2003-12-03T10:05:00Z” /> <saml:AuthenticationStatement AuthenticationMethod=“password” AuthenticationInstant=“2003-12-03T10:02:00Z”> <saml:Subject> <saml:NameIdentifier SecurityDomain=“virginia.edu” Name=“jim” /> </saml:Subject> </saml:AuthenticationStatement> </saml:Assertion>

48. Attribute assertion • An issuing authority asserts that: • subject S • is associated with attributes A, B, C… • with values “a”, “b”, “c”… • Typically this would be gotten from an LDAP repository • “jim” in “virginia.edu” • is associated with attribute “Department” • with value “Computer Science”

49. Example attribute assertion • <saml:Assertion …> <saml:Conditions …/> <saml:AttributeStatement> <saml:Subject> <saml:NameIdentifier SecurityDomain=“virginia.edu” Name=“jim” /> </saml:Subject> <saml:Attribute AttributeName=“Department” AttributeNamespace=“http://virginia.edu”> <saml:AttributeValue>Computer Science </saml:AttributeValue> </saml:Attribute> </saml:AttributeStatement></saml:Assertion>

50. Authorization decision assertion • An issuing authority decides whether to grant the request: • by subject S • for access type A • to resource R • given evidence E • The subject could be a human or a program • The resource could be a web page or a web service, for example