Federated SOA Security Example From the Dutch National Healthcare Exchange

FederatedSOA SECURITYExample from the DutchHealthcare Exchange Program

1. The business rationale People can receive care during their whole life Care is often provided by multiple care institutions Care institutions are in charge of their own registrations + Information about one patient is distributed over many information systems over many care institutions •  There is no complete and accurate “patient record” Federated SOA Security © CSC 2010

For example: “the total hip”•  A woman of 67 years old suffers from heavy pain when she walks, cycles or dances Family doctor•  She visits her family doctor and he prescribes a painkiller•  She takes the painkiller during some time. First with good results but after a while she needs more and more. Her doctor sends her to a physiotherapist•  The physiotherapist sends her to a hospital for an X-ray Pharmacist•  The X-ray shows a worn hip. She’s placed on the waiting list for the hospital for hip replacement•  During the intake for the operation the woman remembers that in her youth she has had allergic reactions against penicillin Physiotherapist•  She is operated on and after that receives therapy from another physiotherapist Hospital Federated SOA Security © CSC 2010

2. Business Constraints •  Security is key. The patient can grant or deny access to his information and may forbid to exchange his patient data •  Healthcare institutions have their own responsibilities. The way information is registered and stored is part of their responsibility for the quality of care provision. So we can’t “replace” their applications with prescribed information systems •  The solution should support small care providers (like family doctors with one PC) as well as the very big ones (like university hospitals with their own dual data center) •  Authorization should be fine-grained. The information available for a healthcare provider should be dependant of his role and the care institution he’s working for Federated SOA Security © CSC 2010

3. Some more detail The Netherlands CSC 2010 © Federated SOA Security

The Netherlands (“Holland”) •  23rd most densely populated country in the world –  almost 1500 people per square mile •  High life expectancy –  82 years for newborn girls, 77 years for boys •  16th largest economy in the world •  Aging population –  More and longer demand for (health-)care –  Working population decreases •  Challenges for healthcare –  Doing more with less –  Growing demand for extramural care Federated SOA Security © CSC 2010

The National Switchboard for healthcare Federated SOA Security © CSC 2010

Smartcard for care providers Federated SOA Security © CSC 2010

4. Architectural starting points - 1•  Patients’ information stays at the source•  The Dutch National Switchpoint is a pointer index•  The Switch Point also retrieves the information from local healthcare information systems and transfers the information to requesting healthcare information systems•  Importance of authentication and autorization – privacy aspects – reliability of information (responsibility) – Citizen Service Number for patients identification – UZI pass for the identification, role and working relationship of doctors etc.•  Importance of logging•  The patient in the driving seat – final autorization of healthcare professionals by the patient – right to see logged information by law Federated SOA Security © CSC 2010

Architectural starting points - 2•  HL7v3 is the protocol to be used for the exchange of information with the National Switchpoint – HL7 is one of the leading standardization organizations within international healthcare – HL7v3 offers semantic interoperability – HL7v3 supports web services / Service Oriented Architecture•  The Switchpoint acts as a “ broker” for the underlying healthcare information systems – Requesting systems don’t have knowledge about addresses etc. this is all handled by the Switchpoint•  The network connections are encrypted using SSL – Authentication on the network layer (SSL) done with the organization’s “ service certificate” – Authentication for the message (token) done with the healthcare providers personal “UZI pass” Federated SOA Security © CSC 2010

Result: The‘virtual patient record’ Information from Healthcare System A Information from Healthcare System B Information from Healthcare System C Federated SOA Security © CSC 2010

5. Basic Security architecturePerimeter 1Use of private networks End-to-end Token based authentication on message level Perimeter 2 Perimeter 2 SSL based on server SSL based on server certificates certificates Healthcare Healthcare organization organization National Switchpoint Federated SOA Security © CSC 2010

Implementation challenges•  Large number of SSL connections to take care of •  2000 concurrent connections growing towards 10.000 connections•  Security token to be checked in every message •  2000 messages/minute growing towards 40.000 messages/minute•  Multiple changes expected in authentication •  SHA-2 for better security •  Support needed for other means of authentication than the UZI-pass •  Other smart cards for public officers •  Delegated authentication for patients portal Federated SOA Security © CSC 2010

Solutions  architectural principles•  “Offload” core system – Move simple tasks, not requiring business logic, to the “outside’ of the switchpoint – Use dedicated (hardware) components when appropriate •  SSL offloaders •  XML security gateways [Layer7]•  Keep communication layers separated•  Define and design “generic authentication and authorization” – Independent from specific implementations of means of authentication – Creating flexibility for changes in the future Federated SOA Security © CSC 2010

Offload Core System Outside world XML Autori- validation SSL zation & Core Business Logic handling & Token handling Consent Generic authentication and autorization Switchpoint Federated SOA Security © CSC 2010

Keep communication layers separated SOAP/XML Application HL7v3 Presentation Layer Session LayerTransport Layer (TCP) SSL Network Layer (IP) Data Layer Physical Layer OSI model Federated SOA Security © CSC 2010

Keep communication layers separated Autori- XML zation validation SSL & & handling Consent Token handling Core Business LogicSSL XML validation HL7 HL7 wrappers content Federated SOA Security © CSC 2010

Generic authentication & authorizationGeneric authentication & authorization XML Autori- validation SSL & zation handling Token & Core Business Logic handling Consent Federated SOA Security © CSC 2010

7. Experiences and lessons learned1.  Develop “generic components” for authentication and authorization. This results in flexibility and better maintainability2.  “Offload” specific tasks, like handling SSL connections, verifying XML structures and handling tokens to dedicated components. This results in scalability3.  Use “Commercial Of The Shelf” products for specific tasks. Invest in learning to know and appreciate these components: they are part of your system4.  It is good practice to put “security” on every layer in your system. However, also put “security” on the relationship between those layers. Federated SOA Security © CSC 2010

http://www.layer7tech.com	501
http://paper.li	9
http://ssg615:8080	1

Federated SOA Security Example From the Dutch National Healthcare Exchange

by Layer 7 Technologies on Dec 05, 2011

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 511

Statistics

Federated SOA Security Example From the Dutch National Healthcare Exchange Presentation Transcript