1 IHE ITI White Paper on Authorization Volume 1 Rough Cut Outline Jörg Caumanns, Raik Kuhlisch, Oliver Pfaff, Olaf Rode, Christof Strack, Heiko Lemke Berlin,

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 Manuel Metz// GIP-DMP

3 Schedule 06. JanInternal Face-to-Face Meeting (ISST, Siemens) 07. JanInternal Online Meeting (ISST, Siemens, SUN) 08. JanPreparation of Slides/Paper for the Editorial Team 09. JanOnline Meeting with Editorial Team (19.00 MEZ) 14. JanUpdate of Initial Paper for Internal Discussion 16. JanInternal Online Meeting (ISST, Siemens, SUN, ELGA) 19. JanDeadline for Internal Comments 20. JanPreparation of the Initial Paper for the Editorial Team 21. JanOnline Meeting with Editorial Team (16.00 MEZ) 24. JanUpdate of Initial Paper and Preparation of ITI Technical Committee JanFace-to-Face Meeting with ITI Technical Committee

4 Storyline of the White Paper There is no “one-fits-all” solution for authorization policies, verifiable attributes, and attribute sources vary granularity of protected items varies deployment varies Therefore the WP provides a generic toolkit of deployable actors and a methodology to tailor this toolkit to a specific healthcare network’s needs and to identify the required transactions. The toolkits reflects the maximal set of attributes and policy sources in a maximally distributed scenario. The methodology helps system architects in selecting the required components and in designing the optimized flow of control. For each component and transaction appropriate standards are named. If possible they are mapped onto existing IHE ITI actors and transactions.

5 Outline 1.Access Control: Motivation and State-of-the-Art 2.Specific Requirements of Federated Healthcare Networks 3.Generic Access Control Model for Federated Healthcare Networks 4.Methodology for Tailoring the Generic Model 5.Sample Adaptations of the Generic Model 6.Standards for Implementing the Actors and Transactions of the Generic Model 7.Appendix: Glossary of Terms 8.Appendix: Standards and Vocabularies for Attribute Names and Values

6 Chapter 1: Access Control – Motivation and State of the Art Motivation Privacy and Data Security Needs-to-Know Principle State of the Art Paradigms: DAC, MAC, RBAC,... Policy Based Access Control (PEP, PDP,...) Standards (SAML, WS*, XACML, XSPA,...) Challenge Solution is driven by the characteristics of the policies: Which information is needed for policy selection/evaluation and how can this information be obtained in an efficient manner? Multiple policy sources and specific workflow aspects add another layer of complexity But: Things must be kept simple to be safe and efficient

7 Chapter 1: Access Control – Motivation and State of the Art Generic Model for Access Control (based on XSPA) Access Control System within each domain Attribute Management (Directories and Services) Domain 1: Context Domains Issuer of a request affecting a protected resource Management of context attributes control of the assertion/message flow Domain 2: Subject Domain (in XSPA part of the issuing domain) Subject authentication Management of subject attributes Domain 3: Resource Domain management of protected resources (e. g. data base) management of resource attributes management of resource security policies policy enforcement and policy decision

8 Generic Model (distributed XSPA) ACS STS Context Domain ACS STS Subject Domain ACS STS Resource Domain context attributes subject attributes resource attributes role activation Identity Prv. PEP / PDP org. security policy request initiator resource Attribute Svc. PEP / PDP

9 Chapter 2: Specific Requirements of (Federated) Healthcare Networks Federated Healthcare Environments Trust Brokerage and Security Token Federation of the Resource Domain (XCA) Federated Identities within the Subject Domain (XUA) Distributed Patient Attributes (XCPI) Session Control vs. Resource Control Granularities and flavours of protected resources The role of the “Purpose” Instantiation of access rights for organizations Resource Security through Role Based Access Control HL7 role engineering Role activation HL7/VA access control matrices

10 Chapter 2: Specific Requirements of (Federated) Healthcare Networks The Role of the Patient Patient Privacy Policies (Consents) DAC-style vs. RBAC-style PPPs client-side vs. resource-side enforcement patient-bound tokens (e. g. EHCs) as access control measures Conclusion: Policies and Attributes Needed patient privacy policy, application policy, resource (data protection) policy subject attributes, resource attributes, activity attributes, context/purpose attributes, patient attributes Binding of policies and attributes (and attribute sources)

11 acute care record Access Control Layering in Healthcare electronic health record medication record e-prescription management application contexts (purpose-driven) medical resources (data-centric) session control (DAC-style) resource control (RBAC-style) federated healthcare infrastructure

12 Session Control In (distributed) medical treatment scenarios, access to medical data is legitimated by a purpose which is implemented by a medical application It is the patient’s right to decide who may act on his data for which purpose. This is reflected by patient-granted admission rights for the corresponding medical services. Examples for admission rights: Person A and Organization B may access my EHR Any physician to whom I handle over my EHC may access my medication record Admission control is often implemented in a service-specific way; e.g.: EHC tickets to access a patient’s e-prescriptions eCR admission codes to access a patient’s case record

13 Resource Control The objective of resource control is to grant permissions (for operations on object types) to only the persons who need these permissions in order to perform their dedicated functional roles within a medical workflow Resource control rights reflect the separation of concerns within an organization and are a measure of data security Example for a resource control access right system: HL7 healthcare scenario roadmap Resource access rights can best be expressed using role-based policies. Nevertheless most existing hospital information systems use hard-coded access rules and proprietary permission hierarchies...

14 Chapter 3: Generic ACS Model for Federated Healthcare Networks Extension and Refinement of the Generic Model (Chapter 1) additional Patient Domain 2 flavours of the resource domain: –resource domain –application domain each domain controls attributes and policies each domain may exist with none, one, or multiple instances

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

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

17 Chapter 3: Generic ACS Model for Federated Healthcare Networks Identification and Authentication Subject Authentication (XUA) Role Attributes and Role Activation Patient Identification Privacy Policy Activation and Session Control Context Activation Application Policy Selection Privacy Policy Selection Separation of DAC- and RBAC-style rules Policy Decision and Enforcement (Context Domain) Policy Decision and Enforcement (App Domain)

18 Chapter 3: Generic ACS Model for Federated Healthcare Networks Resource Control Resource Policy Selection Patient Privacy Policy Push vs. Pull Resource Attribute Retrieval Policy Decision and Enforcement Actors and Transactions Security Token Services, Policy Registries and Policy Repositories, Attribute Services (Directories), PEP and PDP Security Token Retrieval, Policy Retrieval, Attribute Retrieval, Role Activation, Policy Decision and Enforcement Management Interfaces

19 Chapter 4: 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

20 Chapter 4: 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

21 Core Methodology Configuration Attribute Stubs Attribute Value Source Subject ¬ Subject (Resource,App) e.g. Org. Type ID Datatype Internal (Aut/SSO) External (Classes) 1. Define Attributes (Desired Values) No Defaults: AuthZ Model (DAC, MAC, RBAC,...), Attr. Types/Sources Defaults: Syntax of policies 2. Policy building by given syntax  Policy 3. Policy Deployment Policy Svc Management Policy Evaluation Tooltime Runtime ACS PolicyFinder Query (XACML Policy (Set)ID, Target,...) App Request AuthZ Request App Config e. g. XACML PDP

22 Chapter 5: Sample Adaptations of the Generic Model XSPA Actor Deployment and Flow of Control Regional Healthcare Network Based on IHE XDS/XUA Distributed EHR Based on IHE XDS/XCA/XUA eCR Security Architecture BPPC (Context Domain Enforcement vs. Resource Domain Enforcement)

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

24 Chapter 6: Standards Layering Opportunities (Message Header, SOAP Header, SOAP Body) Security Token Encoding and Exchange SAML and WS Trust Subject authentication and subject attribute exchange based on XUA (Protection Token) Encoding and exchange of policy references and policies as security tokens (Supporting Token) Policy Encoding XACML Attribute Management and Attribute Retrieval PWP, PDQ,...

25 Appendix A: Glossary of Terms ResourceSomething of value in a network infrastructure to which rules or policy criteria are first applied before access is granted [RFC 2753] SubjectIdentified and authenticated entity (e. g. a human actor) who wants to access a resource PolicySet of rules to administer, manage, and control access to [network] resources [RFC 3060] ConditionRepresentation of the necessary state and/or prerequi- sites that define whether a policy rule’s actions should be performed [RFC 3198]

26 Appendix B: Standards and Vocabularies for Attribute Names and Values Subject Attributes Administrative Roles Functional Roles Organizational Memberships Organization Types Patient Attributes (if anything but the ID is needed at all) Context Attributes Purpose Date and Time Application Attributes (if anything but the ID is needed at all) Resource Attributes Resource Type