1. 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. 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. 3 Why is Designing an Access Control Solution such a Problem? Dr. Bob is assigned the structured role of “Physician”. This role allows full access to the patient record. Domain B allows full access to the role of “Physician”. Patient “Bambi Smith” has created a consent directive on Domain B. This consent restricts cross-enterprise access to her patient record for... At Domain A organization policies exist to limit “Physician” access to... A policy at Domain B exists to grant cross-enterprise access if and only if an emergency exists. A policy at Domain A states that access to patient data requires the permissions PRD-003, PRD-005,... Examples derived from “XSPA: HIMSS Interop Scenarios – Demonstration of XSPA Profile of SAML”. Jan. 2009

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

5. 5 Scope of the White Paper Within the Scope of the White Paper (Rough) classification of AC models and policies Model based specification of AC solutions Nesting and sequencing policies Model based ACS engineering and reasoning Deployment options for ACS building blocks General considerations for ACS implementations Without the Scope of the White Paper Encoding of consents and policies Role engineering Legal issues Discussion on standards

6. 6 Outline of the White Paper 1.Access Control in Healthcare (Motivation/Outline) 2.State-of-the-Art 3.Policies and Attributes 4.Common Access Control Model for Federated Healthcare Networks 5.Sample Adaptations of the Generic Model 6.Methodology for Using the Generic Model 7.Deployment and Implementation Issues 8.Appendix: Glossary of Terms 9.Appendix: Standards and Vocabularies for Attribute Names and Values

7. 7 Chapter 1: Access Control in Healthcare Motivation Privacy and Data Security Access Control vs. Perimeter Protection Needs-to-Know Principle Typical Access Control Scenarios in Healthcare Objective and Outline

8. 8 Needs-to-Know Principle (e. g. Treatment Contract) The objective of access control is to provide all physicians the information they need 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

9. 9 Perimeter Protection vs. Access Control Perimeter protection is the modern form of a medieval city wall: It hinders intruders from entering the city by limiting entry points and thus providing the ability to control every incoming subject. Among the drawbacks of this security means is that it hinders trade and does not enforce “well behaviour” after the gate has been passed. As soon as data is to be exchanged among medical organizations, both perimeter protection and access control are needed: In the first run gate passing must be restricted to entities that are assumed to be trustworthy (e. g. by implementing bi-directional node authentication). In most cases it is nevertheless not appropriate to allow any entity that regularly passes the gate to access any resource within the organization's IT infrastructure. Therefore more fine grained restrictions on resource access must be provided in order to implement all access control restrictions that hold for resources rather than for the resource managing system.

10. 10 Access Control Use Cases (1/2) Internal Resource Security: Within a hospital access to a patient's medical data is restricted to personnel who is involved with the patient's acute medical treatment and the corresponding administrative activities (e. g. billing). Access to certain sensitive information is further limited to certain functional roles in order to ensure that this information is only disclosed to people who need to know it for a dedicated purpose. Treatment Contract: When signing the treatment contract the patient grants access right to certain administrative and medical data to a commercial organization that provides billing services for the hospital. Patient Privacy Consent: Within a regional healthcare network the ability is provided to exchange medical patient data among the participating medical organizations (e. g. using IHE XDS). When signing to this network a patient may determine which organizations are allowed to request his medical data from other organizations within the network on a regular base.

11. 11 Access Control Use Cases (2/2) Application Policy: A hospital offers its patients the opportunity to use a medication record where all dispensed pharmaceutical products are recorded in order to discover potential interactions. To ensure the consistence and a proper use of this record a policy is agreed upon which states that only pharmacists and the patient himself may add entries to the record while only physicians and the patient himself are allowed to run a check against a new medication. Secondary Use: A patient grants access to certain parts of his medical data to a medical study provided that all data is pseudonymized before use. Breaking Glass: In case of an emergency access restrictions from patient provided policies and internal security regulations are overwritten by a dedicated emergency policy which allows any physician to access all medical data of the patient. Part of this emergency policy is that the physician has to legitimate his access following the first aid treatment by filling an emergency access form.

12. 12 Authorization vs. Organization of Labor “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 technical access control means because they violate the underlying 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 of his staff in order to control quality

13. 13 Chapter 2: State-of-the-Art State of the Art Principles of Secure Design Paradigms: DAC, MAC, RBAC,... Policy Based Access Control (PEP, PDP,...) Generic Model for Access Control (based on XSPA) Access Control System within each domain Management of Attributes and Policies Context Domain Subject Domain (in XSPA part of the issuing domain) Resource Domain Session Control vs. Resource Control Granularities and flavours of protected resources Automated workflows The role of the “Purpose” Instantiation of access rights for organizations Federated Healthcare Environments Trust Brokerage and Security Token Federation of the Resource Domain (XCA) Federated Identities within the Subject Domain (XUA) Distributed Patient Attributes (PIX, XCPI)

14. 14 Principles of Secure Design Functional Design (incl. Policies) ACS DesignACS Implementation Economy of MechanismX Complete MediationX Open DesignX(x) Least-Common MechanismX(x) Fail-Safe DefaultsXX Separation of PrivilegeX Least PrivilegesXX Psychological AcceptabilityXX Reluctance to TrustX(x) Privacy ConsiderationX IsolationXX

15. 15 Use Cases’ Preface: Applications as Legal Frameworks XDS: Shared Medical Data Privacy Policy Security Policy Purpose of Use XDS: Shared Medical Data Privacy Policy Security Policy Purpose of Use EHR, PHR, eCR,... App. Policy activates US Perseption e.g. IHE ITI European Perception e.g. eCR, ELGA, epSOS,...

16. 16 Access Control Paradigms Discretionary Access Control (DAC): Each Object is assigned to a subject (e. g. owner) who is able to assign permissions to other subjects. These subjects might be indiviuals or groups. Considered harmful (no enforcement for SoD, open groups, (nearly) no chance to enforce superordinate security policies) Mandatory Access Control (MAC): Subjects and Objects are assigned to partially ordered security levels (clearance/classification levels) authorization based on rules on permissions e. g. *-property: no read up – no write down Role-Based Access Control (RBAC): Permissions (actions on object) soley on roles Centralized administration of roles and permissions (policy driven, context aware) Extensible: Role hierarchies, SoD constraints,...

17. 17 Access Control Paradigms in Healthcare The patient is the sovereign of his data (“my body – my data – my control”). ACS following this notion always include a good portion of DAC e. g. German “Gesundheitskarte” e. g. ELGA in Austria in an intra-enterprise scenario part of the right to pass permissions is handled over to the care provider by the treatment contract (e. g. give data access to consultants) The “needs-to-know” principle implies RBAC-style policies. HL7, VA, OASIS follow this direction with respect to healthcare ACS. e. g. HL7 RBAC permission catalog MAC requires subject-classes and object-classes to be partially ordered (a second dimension – e. g. specialty - can be added by using the MAC lattice-model). Assuming that functional roles are used for permission assignment, this partial order must be either coarse-grained or artificially constructed. e. g. HL7 confidentiality codes e. g. IHE BPPC

18. 18 Example for a Combination of DAC and RBAC RBAC clinic RBAC GP DAC sync patient decides which organizations take part in a co-operative medical treatment for a certain disease. Only staff members of these organizations may access his shared data. organization of labor at clinic and practice determines which roles may access which portions of the patient’s shared data

19. 19 Resource Access Policy: Who is allowed to access my EHR for the given purpose/context? Resource Behaviour Policy: How may authorized subjects work with my EHR? EHR Definition Privacy Consent National Law Agreement Configuration AuthorizationScope, Procedure,... Regulations Access Policies vs. Behaviour Policies

20. 20 acute care record Resources: Applications, Services, Data,... electronic health record medication record e-prescription management application contexts (purpose-driven) medical resources (data-centric) session control (e. g. DAC-style) resource control (e. g. RBAC-style) federated healthcare infrastructure

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

22. 22 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 mean of data security Example for a resource control access rights 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...

23. 23 Clinical Information System Distributed medical data set (e. g. XDS) local medical data patient consent shared policy configures

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

25. 25 SOA Security: Separation of Authentication and Authorization resource-side ACS user-side ACS

26. 26 XSPA ACS Framework (WS-Trust Implementation)

27. 27 Medical Data Access within Organizations (2 PEPs!) Deployment of PEP/PDPs depends on the level of Trust! (provider must in any case verify, that the consuming organization is authorized. But does he even have to verify that the role of the accessory matches the patient’s consent or an appropriate organization of work?)

28. 28 Generic Model (XSPA + externalized IdP) 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 policy activation security policy privacy policy policy activation circle of trust patient attributes enter context consent

29. 29 Generic Model (XSPA + externalized IdP) 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 policy activation security policy privacy policy policy activation circle of trust patient attributes enter context XUA XDS XUA XCA PIX/PDQ consent PIX/PDQ PWP

30. 30 Chapter 3: Policies and Attributes Resource Security through Role Based Access Control HL7 role engineering Role activation HL7/VA access control matrices The Role of the Patient Patient Privacy Policies (Consents) DAC-style vs. RBAC-style PPPs client-side vs. resource-side enforcement Prefetching of patient data 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)

31. 31 HL7 Role Engineering

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

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

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

35. 35 Chapter 4: Common Healthcare ACS Model Extension and Refinement of the Basic Model Identification and Authentication Subject Authentication (XUA) Role Attributes and Role Activation Patient Identification Privacy Policy Activation and Session Control Context Activation Application Policy Activation Privacy Policy Activation Separation of DAC- and RBAC-style rules Policy Decision and Enforcement Resource Control Resource Policy Selection Resource Attribute Retrieval Policy Decision and Enforcement Actors and Transactions

36. 36 4-Domain Model 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

37. 37 5-Domain Model 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

38. 38 Building Blocks attribute-ID (stub) attribute value policy subject-ID role-ID (adm) policy-ID context-ID purpose-ID role-ID (func) patient-ID resource-ID activity-ID policy decision policy enforcement context activation role activation Enter Context policy activation

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

40. 40 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 2 1 3 4 5 6 7 8 9 10 11

41. 41 Use-Cases: Exemplary Consent CIS Clinic A IT Dr. Smith Consent exchange I hereby authorise Dr. Smith to share all my diabetes-related medical data with the Clinic A in case that I require a treatment while I am at Clinic A. EU data protection

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

43. 43 Use-Cases: Implementation by (specific) Policies CIS Clinic A IT Dr. Smith Patient Privacy Policy : Dr. Smith diabetologist working in Clinic A currently treating me diabetic-related data XCA Resource Security Policy : representative of Clinic A diabetic-related data Resource Security Policy: role diabetologist working in Clinic A involved in treatment functional/organisational division pre- negotiated trust

44. 44 Use-Cases: Alignment to Domain Model Resource Security Policy : representative of Clinic A diabetic-related data Resource Security Policy: role diabetologist involved in treatment CIS Clinic A IT Dr. Smith pre- negotiated trust Consent patient domain context domain resource domain application domain subject domain

45. 45 Use-Cases: Alignment to Domain Model 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 involved in treatment role diabetologist repres. of Clinic A diabetic related data Patient Privacy Policy : Dr. Smith diabetologist working in Clinic A currently treating me diabetic-related data

46. 46 eCR Access Control Pattern context node Subject Domain authenticate Identity Prv. Attribute Svc XUA + administrative roles enter context Policy Vocabulary Rolicy Templates access policy activation eCR Record Reg. eCR Data Services Token Mgmt. PEP PDP Application Domain Registry Repository Patient Domain Resource Domain Role Policies (RBAC) STS admission policy activation STS ACL (DAC) Patient Consents PEP PDP eCR locator eCR consumer 1 3 Policy-ID 4 Policy Cache 5 Policy 2

47. 47 epSOS Patient Summary Access Control (just an option..) Subject Domain authenticate Identity Prv. Attribute Svc XUA + administrative roles enter context Pivot Vocabulary Mapping tables access policy activation PS Data Services PEP PDP Application Domain Repository Patient Domain Patient Consents STS PS consumer 1 National Security Policy (RBAC) 2 3 Resource Domain Patient Home Country Physician Home Country NCP-Network

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

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

50. 50 TP20: Development of Security and Privacy Protections

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

66. 66 Policy Pull vs. Policy Push

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

68. 68 Attribute Pull (PIP) vs. Attribute Push PDP Requestor Resource PEP PIP PDP Requestor Resource PEP PIP Service Request without Attributes (PULL) Service Request with Attributes (PUSH)

69. 69 Use-Case: Attribute Pull Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID org ID resource type patient ID purpose ID patient ID subject ID policy 1 2 3 4 subject ID

70. 70 Use-Case: Attribute Pull, Policy Pull Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID purpose ID patient ID subject ID 1 2 3 4 org ID

71. 71 Use-Case: Split PEP/PDP Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID subject ID 1 2 3 4 org ID PEP / PDP policy patient ID policy decision

72. 72 Use-Case: Client-side PEP/PDP Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role patient ID resource type patient ID subject ID 1 2 3 org ID patient ID

73. 73 Use-Case: Client-side PEP/PDP with SSO Context Domain STS Subject Domain STS Patient Domain Resource Domain policy purpose ID resource ID policy activation Attribute Svc PEP / PDP request initiator resource subject role resource type patient ID 1 2 3 org ID patient ID subject role org ID patient ID subject ID

74. 74 Deployment and Evaluation Deployment of the single domains (and their respective building block) onto nodes subject domain in usually closely related to the context domain. But: providing it close to the resource makes attribute pull easier deployment of the patient domain depends on the use of pull/push and on implementation issues (e. g. if XDS is used for policy management) Evaluation of the various deployment opportunities with respect to principles of secure design management authorities and policies security consideration (what assumptions can be made about the nodes’ security contexts)...

75. 75 Chapter 7: Deployment and Implementation Issues 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,...

76. 76 Authorization Subsystem - How to Employ? HTTP header SOAP header SOAP body WS application WS-stack e.g. JAX-WS RI/ WSIT HTTP-stack e.g. Tomcat servlet container PEP  PEPs residing in HTTP-stacks: Decoupled from application sources or binaries  Limited to coarse-grained request authorization (may subject X access the service application?)  Limited to HTTP authentication protocols  Hard to hand-over properties to application PEP  PEPs residing in WS-stacks: Decoupled from application sources or binaries  Allows fine-grained request authorization as far as authorization-relevant information is available in request Supports WS authentication protocols  Relies on WS-stack to hand-over properties to application PEP  PEPs residing in WS applications: Allows arbitrarily fine-grained request authorization (may subject X call method Y upon resource Z?)  Needs to consume authentication state from WS-stack

77. 77 Security Token Chaining (eCR Example)

78. 78 PEP/PDP Deployment (eCR Example)

79. 79 Technologies for Communication Security in Web Services XML Signature Provides msg authentication W3C standard XML Encryption Provides msg encryption W3C standard SAML assertion Is a kind of OASIS standard (SAML TC) Security token Provides user authentication WSFED Is an extension to OASIS work- in-progress SOAP Message Security OASIS standard (WSS TC) Allows profiling of WS-SecurityPolicy OASIS standard (WS-SX TC) WS-Trust Defines WSs for managing OASIS standard (WS-SX TC) Defines security for STSs WS-Policy Allows publishing of W3C work- in-progress

80. 80 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]

81. 81 Appendix B: Standards and Vocabularies for Attribute Names and Values XSPA Conformance Attributes ASTM E1986-98(2005): Standard Guide for Information Access Privileges to Health Information. HITSP/TP20: HITSP Access Control Transaction Package HL7: RBAC Consent related vocabulary including Confidentiality Codes. HL7: (RBAC) Healthcare Permission Catalog. RFC 2798 (as used by IHE PWP)