FederatedSOA SECURITYExample from the DutchHealthcare Exchange Program
1. The business rationale              People can receive care during their whole life              Care is often provided...
For example: “the total hip”•  A woman of 67 years old suffers from heavy pain when   she walks, cycles or dances         ...
2. Business Constraints              •  Security is key. The patient can grant or deny access to his                 infor...
3. Some more detail                            The Netherlands CSC 2010                                          ©   Feder...
The Netherlands (“Holland”)       •  23rd most densely populated country in the world         –  almost 1500 people per sq...
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 poi...
Architectural starting points - 2•  HL7v3 is the protocol to be used for the exchange of information with the   National S...
Result: The‘virtual patient record’                                       Information from                                ...
5. Basic Security architecturePerimeter 1Use of private networks                      End-to-end                          ...
Implementation challenges•  Large number of SSL connections to take care of    •  2000 concurrent connections growing towa...
Solutions  architectural principles•  “Offload” core system – Move simple tasks, not requiring business logic, to the “ou...
Offload Core System  Outside world                                      XML                                               ...
Keep communication layers separated                             SOAP/XML     Application                             HL7v3...
Keep communication layers separated                                                  Autori-                              ...
Generic authentication & authorizationGeneric authentication & authorization                                  XML         ...
7. Experiences and lessons learned1.  Develop “generic components” for authentication and    authorization. This results i...
Upcoming SlideShare
Loading in...5
×

Federated SOA Security Example From the Dutch National Healthcare Exchange

2,237

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
2,237
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
17
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Federated SOA Security Example From the Dutch National Healthcare Exchange

  1. 1. FederatedSOA SECURITYExample from the DutchHealthcare Exchange Program
  2. 2. 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
  3. 3. 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
  4. 4. 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
  5. 5. 3. Some more detail The Netherlands CSC 2010 © Federated SOA Security
  6. 6. 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
  7. 7. The National Switchboard for healthcare Federated SOA Security © CSC 2010
  8. 8. Smartcard for care providers Federated SOA Security © CSC 2010
  9. 9. 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
  10. 10. 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
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. Generic authentication & authorizationGeneric authentication & authorization XML Autori- validation SSL & zation handling Token & Core Business Logic handling Consent Federated SOA Security © CSC 2010
  19. 19. 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
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×