IHE ITI White Paper on Authorization

1. IHE ITI White Paper on Authorization Rapid Walk-Through Jörg Caumanns, Raik Kuhlisch, Oliver Pfaff, Olaf Rode, Christof Strack, Heiko Lemke Chicago, 26.01.09

2. Editing Team • Authors: Raik Kuhlisch, Jörg Caumanns // Fraunhofer ISST Oliver Pfaff, Markus Franke // Siemens IT Solutions // and Services Christof Strack, Heiko Lemke // SUN Microsystems • Supervisior: Rob Horn // Agfa Healthcare • Editorial Team: John Moehrke // GE Healthcare Lynn Felhofer // MIR Manuel Metz // GIP-DMP

3. Storyline of the White Paper • There is no “one-fits-all” solution for authorization • access control requirements and paradigms vary • policies, verifiable attributes, and attribute sources vary • granularity of protected items varies • deployment varies • Therefore this white paper does not provide a single deployment of ACS and its building blocks among static domains. It rather provides healthcare system architects with a model and a corresponding methodology: • The model describes how the building blocks of a distributed access control solution can be described in a manner that is both deployment and implementation independent. • The methodology defines how system architects can use the model to reason about different realization opportunities in order to discover the most appropriate deployment and flow of control with respect to the given application architectures requirements. • Deployment and implementation issues are handled in a generic way. The application of concrete standards will be subject to future profiles.

4. Outline of the White Paper [59.5 pages] • Access Control in Healthcare (Motivation/Outline) [ 2.5 pages] • State-of-the-Art [ 8.5 pages] • Policies and Attributes [ 7.0 pages] • Common Access Control Model [ 8.5 pages] • Sample Adaptations of the Common Model [10.0 pages] • Methodology for Using the Common Model [12.0 pages] • Deployment and Implementation Issues [ 8.0 pages] • Appendix: Glossary of Terms [ 1.5 pages] • Appendix: Vocabularies for Attribute Names and Values [ 1.5 pages]

5. Chapter 1: Access Control in Healthcare [2.50 pages] • Motivation [0.75 page] • Typical Access Control Scenarios in Healthcare [1.00 page] • Objective and Outline [0.75 page]

6. Chapter 2: State-of-the-Art [8.5 pages] • State of the Art • Principles of Secure Design [1.00 pages] • Paradigms: DAC, MAC, RBAC, ... [1.50 pages] • Policy Based Access Control (PEP, PDP, ...) [1.00 pages] • SOA Security • Decouple Authorization and Authentication [0.50 pages] • Decouple Security Object Lookup and Use [0.50 pages] • Access Control System • Conceptual Model vs. Deployment vs. Implementation [1.00 pages] • Context Domain, Subject Domain, Resource Domain [1.00 pages] • Management of Attributes and Policies [0.50 pages] • Trust Relationships [0.50 pages] • Federated Healthcare Environments [1.00 pages] • Federation of the Resource Domain (XCA) • Federated Identities within the Subject Domain (XUA) • Distributed Patient Attributes (PIX, XCPI)

7. XSPA SAML Profile / HITSP TP20 High-Level Interactions trust relationship [SOA-style security!]

8. Attribute Svc Identity Prv. PEP / PDP PEP / PDP Policy Authority Policy Authority Attribute Svc Attribute Svc Core Model (XSPA + externalized IdP) Subject Domain ACS enter context STS Context Domain circleof trust STS ACS STS request initiator ACS resource Resource Domain

9. Attribute Svc Identity Prv. PEP / PDP PEP / PDP Policy Authority Policy Authority Attribute Svc Attribute Svc Core Model (XSPA + externalized IdP) Subject Domain PWP ACS enter context STS Context Domain XUA PIX/PDQ XUA circleof trust STS XCA ACS PIX/PDQ STS request initiator XDS ACS resource XDS, PHR, ... Resource Domain

10. Chapter 3: Policies and Attributes [7.00 pages] • Granularities and Flavours of protected Resources [2.00 pages] • Application, Session, Service, Data, ... • Nesting and Sequencing of Policies • Access Policies vs. Behaviour Policies • Instantiation of access rights for organizations • The Role of the Patient [1.50 pages] • Consents and Policies • client-side vs. resource-side enforcement • patient-bound tokens (e. g. EHCs) • Resource Security through Role Based Access Control [2.00 pages] • Needs-to-Know Principle • Structural vs. Functional Roles (HL7 role engineering) • Policy Conflicts • Policy and Attribute Sources [1.50 pages] • Policy Authorities • Attribute Value Authorities • Binding of policies and attributes

11. Applications as Legal Frameworks Purpose of Use Privacy Policy EHR, PHR, eCR, ... activates App. Policy Security Policy XDS: Shared Medical Data

12. Access Policies vs. Behaviour Policies Resource Access Policy:Who is allowed to access my EHRfor the given purpose/context? Privacy Consent National Law Authorization Scope, Procedure, ... Agreement Configuration Regulations EHR Definition ResourceBehaviour Policy:How may authorizedsubjects work with myEHR?

13. Needs-to-Know Principle (e. g. Treatment Contract) The objective of access control is to provide all physicians the information theyneed to know in order to treat the patient the best way - while respecting the patient’s right towards self-determination - while protecting the confidentiality and integrity of medical data

14. HL7 Role Engineering

15. Authorization vs. Organization of Labor Bold statement is too rigid. The problem must be discussed in more depth in the WP. • “Patient has specified constraints that would limit of all oncologists, access to the radiology portion of the patient record.„ (taken from Proposed Use Cases for XSPA TC) • „Patient has specified constraints that would exclude the head of the radiologic dept. access to the radiology portion of the patient record.„ (opt-out scenario) • These consents must not be enforced by technicalaccess control means because they violate theunderlying organization of labor! • e. g. oncologists „must know“ radiology data in order to decide on a surgery • e. g. head of dept. „must know“ the work results ofhis staff in order to control quality

16. resource-ID policy consumer res.type-ID resource provider policy activation policy decision patient-ID context-ID policy-ID * subject-ID attribute value * attribute value * role-ID (func) acceptor deny role-ID (adm) purpose-ID activity-ID ... evaluates represents policy-ID * policy Attributes and Policies

17. Chapter 4: Common Healthcare ACS Model [8.5 pages] • Introduction of the model [2.0 pages] • Identification and Authentication [1.5 pages] • Subject Authentication (XUA) • Role Attributes and Role Activation • Patient Identification • Privacy Policy Activation and Session Control [2.5 pages] • Context Activation • Application Policy Activation • Privacy Policy Activation • Separation of DAC- and RBAC-style rules • Policy Decision and Enforcement • Resource Control [2.5 pages] • Resource Policy Selection • Resource Attribute Retrieval • Policy Decision and Enforcement

18. 4-Domain Model Context Domain Subject Domain org. security policy ACS ACS subject attributes context attributes STS STS Attribute Svc. role activation PEP / PDP Identity Prv. request initiator ACS ACS resource attributes consent activation STS STS org. security policy patient privacy policy (consent) PEP / PDP resource Resource Domain Patient Domain

19. 5-Domain Model Subject Domain Context Domain ACS subject attributes org. security policy STS ACS Attribute Svc. context attributes Identity Prv. STS role activation PEP / PDP request initiator ACS application attributes STS app. security policy PEP / PDP ACS consent activation STS Application Domain patient privacy policy (consent) Patient Domain ACS resource attributes STS org. security policy PEP / PDP resource Resource Domain

20. Role Activation and Permission Assignment (XSPA) permission catalogue role activation

21. Policy Activation (Example: Consent) - XSPA POU and User Based Access (UBA) Control Resource Object Masking (MA)

22. context activation role activation policy enforcement policy decision policy activation Attribute Usage subject-ID Enter Context org.-ID context-ID role-ID (struct) role-ID (func) activity-ID purpose-ID policy resource-attr patient-ID policy-ID

23. Conclusion • Using the same set of building blocks (actors) and messages (transactions) very different flows of control can be realized in order to match the non-functional requirements of the application scenario. • Different domains use building blocks with identical functionality and semantics. Therefore these blocks are generic in away that they are independent from their environment. • There are different opportunities to implement the actors and transactions that make up the common building blocks. But: To allow for a multi-vendor strategy and for cross-enterprise communication these implementations must be interoperable. • There is a need for interoperability profiles (comparable to XUA) for policy activation, attribute retrieval, and attribute/policy integration into transactions.

24. To be done: Definition of re-usable building blocks • Identity Provider Actor: XUA + Attributes (extension to XUA?) • Attribute Service Actor: encapsulates LDAP services; provides attribute values (if bound to requestor domain, PWP will do for now) • Role Activation Actor: receives XUA+ and provides functional role (no interop problem except agreement on codes; not conceptually mature) • Policy Activation Actor: 1. receives XUA+, attributes and provides policy or policy ID 2. receives policy-ID and provides policy • PEP/PDP Actor: receives XUA+, attributes and (opt.) policy; consumes policy (opt); consumes attributes (opt.), provides policy decision, consumes audit trail

25. To be done: Using IHE Profiles as a Base for the BB • Policy activation using XDS • Dealing with BPPC (rough cut; details in the samples chapter) • Using PWP for subject attribute retrieval • Using XUA for Identity Provisioning

26. Chapter 6: Methodology • Policy Determination • Session Control vs. Resource Control • Policy Authorities • Paradigms for Patient Privacy Policy, App Policy, Resource Policy • Policy Assignment (Indexing for Retrieval) • Attribute Identification • Identification of Attribute Stubs • Domain Assignment • Policy Assignment • Specification of Attribute Value Sources • Policy Management • Policy Encoding • Policy Deployment

27. Chapter 6: Methodology • Access Control Systems within the Domains • PEP/PDP Placement • Policy Retrieval (Pull/Push) • Attribute Retrieval (Pull/Push) • Authorization Request Interface • Integration of the ACSs into the Application Control Flow • Session Management (if required) • Mapping of Resource Requests onto Authorization Requests • Security Token Control Flow • Policy Lifecycle Management

28. TP20: Development of Security and Privacy Protections

29. Clinic A CIS Use-Cases: Exemplary Consent I hereby authorise Clinic A to share all my diabetes-relatedmedical data with diabetologists at Clinic B in case that I require a treatment while I am at Clinic B. Consent Clinic B CIS exchange

30. Clinic A CIS Use-Cases: Definition of (umbrella) Policies I hereby authorise Clinic A to share all my diabetes-related medical data with the diabetologists of Clinic B in case that I require a treatment while I am at Clinic B. enables / legitimates Consent XDSXCA forms Clinic B • Patient Privacy Policy: • Clinic A as source • diabetologist • working in Clinic B • currently treating me • diabetic-related data CIS governs

31. Use-Cases: Alignment to Domain Model Subject Domain involved intreatment role diabetologistrepres. of Clinic A Context Domain ACS subject attributes STS ACS Attribute Svc. context attributes Identity Prv. STS role activation PEP / PDP request initiator diabetic related data ACS consent activation ACS resource attributes STS STS patient privacy policy (consent) org. security policy PEP / PDP Patient Domain resource • Patient Privacy Policy: • Clinic A as source • diabetologist • working in Clinic B • currently treating me • diabetic-related data Resource Domain

32. Core Methodology • Multistep process that distinguishes between: • Tooltime and • Runtime activities • No Defaults: • Authorization Model (DAC, MAC, RBAC, ...), • Attribute Types and Sources • Defaults: • Syntax of policies

33. Core Methodology (Tooltime) • 1. Define Attributes (Desired Values) Configuration Attribute Value Source Subject Attribute Stubs ¬ Subject (Resource,App) e .g. Org. Type Internal (Aut/SSO) External (Classes) Datatype ID

34. policy decision policy activation Attribute Stub Definition (Example) • I hereby authorise Clinic A to share all mydiabetes-relatedmedical data with Diabetologists at Clinic B in case that I require a treatment at Clinic B. • Patient Privacy Consent Model resource ID my medical data res.type-ID diabetes related patient-ID role-ID Diabetologist purpose-ID treatment org-ID clinic A policy

35. policy activation policy decision Attribute Stub Definition (Example) • I hereby authorise Clinic A to share all mydiabetes-relatedmedical data with Diabetologists at Clinic B in case that I require a treatment at Clinic B. • Patient Privacy Consent Model resource ID my medical data resource attribute resource attribute context attribute res.type-ID diabetes related patient-ID role-ID Diabetologist subject attribute purpose-ID treatment context attribute org-ID clinic A policy subject attribute

36. Use-Case: Attributes subject ID org ID patient ID Subject Domain Context Domain subject role STS role activation org ID Identity Prv. purpose ID STS request initiator ACS resource ID resource type PEP / PDP resource Resource Domain

37. Core Methodology (Tooltime) • 2. Policy Building by Given Syntax Policy Configuration Attribute Value Source Subject Attribute Stubs ¬ Subject (Resource,App) e .g. Org. Type Internal (Aut/SSO) External (Classes) Datatype ID

38. Core Methodology (Tooltime) • 3. Policy Deployment Policy Service Management Policy Configuration Attribute Value Source Subject Attribute Stubs ¬ Subject (Resource,App) e .g. Org. Type Internal (Aut/SSO) External (Classes) Datatype ID

39. Use-Case: Policy subject ID org ID patient ID Subject Domain Context Domain subject role STS role activation Identity Prv. org ID purpose ID STS request initiator STS ACS policy activation resource ID patient privacy policy resource type PEP / PDP Patient Domain resource Resource Domain

40. Core Methodology (Runtime) • Service Request • Authorization Request Generation Business Service 1 Requestor Configuration 2 Access Control System

41. Use-Case: Initial Flow of Control subject ID org ID patient ID Subject Domain Context Domain subject role STS role activation Identity Prv. org ID purpose ID STS request initiator STS policy activation resource ID patient privacy policy resource type PEP / PDP Patient Domain resource Resource Domain

42. Core Methodology (Runtime) Application • 2. Authorization Request Processing • (Policy Discovery and Evaluation) Configuration PEP PDP Policy Finder ACS Resource Policy Service Management Policy

43. 4 3 2 1 Use-Case: Policy Retrieval subject ID org ID patient ID Subject Domain Context Domain subject role STS role activation Identity Prv. org ID purpose ID STS request initiator STS policy activation resource ID patient privacy policy resource type PEP / PDP Patient Domain resource Resource Domain

44. Use-Case: Attribute Flow subject ID org ID patient ID Subject Domain Context Domain subject role subject ID STS role activation Identity Prv. org ID purpose ID STS XUA org ID request initiator XUA subject role purpose ID patient ID STS patient ID policy activation resource ID patient privacy policy resource type PEP / PDP Patient Domain resource Resource Domain

45. Use-Case: Attribute Flow [Patient Safety Mode] subject ID org ID patient ID Subject Domain Context Domain subject role STS role activation Identity Prv. org ID purpose ID STS request initiator XUA org ID purpose ID patient ID STS policy activation resource ID PEP / PDP resource type default policy Patient Domain resource Resource Domain

46. Use-Case: Single Sign-On Subject Domain subject ID patient ID org ID subject role XUA subject role STS Context Domain Identity Prv. org ID role activation purpose ID STS subject role request initiator XUA org ID purpose ID patient ID STS patient ID policy activation resource ID patient privacy policy resource type PEP / PDP Patient Domain resource Resource Domain

47. Configuration Opportunities may as well be pushed with request caller-side vs. resource-side enforcement may be pushed with request as security token may as well be pushed with request

48. Policy Pull vs. Policy Push

49. 2 3 4 1 Use-Case: Policy Push Subject Domain subject ID patient ID org ID subject role XUA subject role STS Context Domain org ID Identity Prv. role activation purpose ID Resource does not have to know where policies are kept. Client may cache policies. Processing on server can start immediately.Appropriate for highly distributed and dynamic environments. STS request initiator subject role org ID XUA patient ID policy STS purpose ID policy activation resource ID patient ID policy resource type PEP / PDP Patient Domain resource Resource Domain

50. 4 1 3 Use-Case: Policy on my Memory-Stick Subject Domain subject ID patient ID org ID subject role XUA subject role STS Context Domain org ID Identity Prv. role activation purpose ID STS Requires patient to be in place when his data is accessed. request initiator subject role org ID XUA policy purpose ID STS resource ID patient ID Bio policy sign resource type PEP / PDP Patient Domain (USB) resource Resource Domain