More Related Content
Similar to Federated SOA Security Example From the Dutch National Healthcare Exchange
Similar to Federated SOA Security Example From the Dutch National Healthcare Exchange (20)
More from CA API Management
More from CA API Management (20)
Federated SOA Security Example From the Dutch National Healthcare Exchange
- 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. 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. 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. 3. Some more detail
The Netherlands CSC 2010
©
Federated SOA Security
- 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
- 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. 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. 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. 5. Basic Security architecture
Perimeter 1
Use 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. 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. 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. 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. Keep communication layers separated
SOAP/XML
Application
HL7v3
Presentation Layer
Session Layer
Transport Layer (TCP)
SSL
Network Layer (IP)
Data Layer
Physical Layer
OSI model
Federated SOA Security © CSC 2010
- 17. Keep communication layers separated
Autori-
XML zation
validation
SSL &
&
handling Consent
Token
handling Core Business Logic
SSL
XML
validation
HL7
HL7
wrappers
content
Federated SOA Security © CSC 2010
- 18. Generic authentication & authorization
Generic authentication & authorization
XML
Autori-
validation
SSL & zation
handling Token & Core Business Logic
handling Consent
Federated SOA Security © CSC 2010
- 19. 7. Experiences and lessons learned
1. Develop “generic components” for authentication and
authorization. This results in flexibility and better maintainability
2. “Offload” specific tasks, like handling SSL connections, verifying
XML structures and handling tokens to dedicated components.
This results in scalability
3. Use “Commercial Of The Shelf” products for specific tasks. Invest
in learning to know and appreciate these components: they are
part of your system
4. 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