Next Generation Standards Based RHIO Security Infrastructure <ul><ul><li>MS-HUG Tech Forum </li></ul></ul><ul><ul><li>HiMS...
Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li...
<ul><li>Saint Francis Heart Hospital </li></ul><ul><li>New Cardiac Care Acute Care Facility  - 2004 </li></ul><ul><li>All ...
<ul><li>Saint Francis Heart Hospital </li></ul><ul><li>New Cardiac Care Acute Care Facility  - 2004 </li></ul><ul><li>All ...
<ul><li>Saint Francis Heart Hospital </li></ul><ul><li>New Cardiac Care Acute Care Facility  - 2004 </li></ul><ul><li>All ...
Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li...
Evolution of Distributed Systems <ul><li>Web Services </li></ul><ul><li>Open, Industry-Wide Standards </li></ul><ul><li>Se...
The WS-* Specifications <ul><li>Defined </li></ul><ul><ul><li>A collection of standards that provide for secure, transacte...
WS-* Specifications http://msdn.microsoft.com/webservices/webservices/understanding/specs/ XML Xml Namespaces Infoset Mess...
WSE Defined <ul><li>Microsoft Web Service Enhancements </li></ul><ul><ul><li>A secure, distributed messaging framework tha...
WSE 3.0 Coverage of WS-* XML Xml Namespaces Infoset Messaging SOAP WS-Addressing MTOM Security WS-Security WS-SecurityPoli...
WSE’s Place in the MS Stack <ul><li>Development </li></ul><ul><ul><li>Designed for .NET </li></ul></ul><ul><ul><ul><li>C# ...
Interoperability <ul><li>Primary MS Partners for WS-* are IBM and BEA </li></ul><ul><ul><li>Java will have enterprise-grad...
Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li...
System Goals <ul><li>The architecture should enable RHIOs to seamlessly share information  </li></ul><ul><li>Support heter...
System Requirements <ul><li>Clinical data must pass directly from the sending institution to the receiving institution; no...
Top-level Architecture Blinded Record Index (BRI) … … Site B Adapter Site C Adapter Site A Adapter
Security Checklist <ul><li>Identity verification </li></ul><ul><li>Data confidentiality </li></ul><ul><li>Data origin </li...
Design Process <ul><li>Define trust boundaries </li></ul><ul><li>Model threats </li></ul><ul><li>Design security solution ...
Security Implementation Choices <ul><li>Authentication </li></ul><ul><ul><li>Direct </li></ul></ul><ul><ul><ul><li>Windows...
Direct Authentication <ul><li>Benefits </li></ul><ul><ul><li>Simple </li></ul></ul><ul><ul><li>Compatible: It’s easy to le...
Kerberos Authentication <ul><li>Benefits </li></ul><ul><ul><li>Sessions: client need only authenticate once to interact wi...
X.509 Authentication <ul><li>Benefits </li></ul><ul><ul><li>Supports sessions </li></ul></ul><ul><ul><li>Broadly accepted:...
Security Token Service (STS) <ul><li>Benefits </li></ul><ul><ul><li>Can support cross-organization authentication </li></u...
Top-level Architecture Revised Blinded Record Index (BRI) … … Security Token Service (STS) Site B Adapter Site C Adapter S...
Communication Scenarios <ul><li>Site sending data to BRI </li></ul>Blinded Record Index (BRI) Security Token Service (STS)...
Communication Scenarios Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 1 2 3 BRI requests a security token ...
Communication Scenarios Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 1 2 3 Site A requests a security tok...
Communication Scenarios Security Token Service (STS) 3 1 1 2 3 Administrator provides new site information STS generates a...
Security Checklist <ul><li>Identity verification </li></ul><ul><li>Data confidentiality </li></ul><ul><li>Data origin </li...
Adapter Architecture Host System Adapter Internal Network Local Data Service Clinical Data Service Data Transfer Service I...
Communication Scenarios Internal Network External Communication Perimeter Service Router Audit DB 1 2 Data Transfer Servic...
Communication Scenarios Service-to-Service Communication 1 Send message signed by service account with Windows Authenticat...
Security Checklist <ul><li>Identity verification </li></ul><ul><li>Data confidentiality </li></ul><ul><li>Data origin </li...
In Summary <ul><li>RHIOs require </li></ul><ul><ul><li>High security </li></ul></ul><ul><ul><li>Solid interoperability </l...
Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li...
Upcoming SlideShare
Loading in …5
×

Next Generation Standards Based RHIO Security Infrastructure

414 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
414
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Next Generation Standards Based RHIO Security Infrastructure

  1. 1. Next Generation Standards Based RHIO Security Infrastructure <ul><ul><li>MS-HUG Tech Forum </li></ul></ul><ul><ul><li>HiMSS 2006 </li></ul></ul>
  2. 2. Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li></ul><ul><ul><li>The WS-* specifications </li></ul></ul><ul><ul><li>WSE defined </li></ul></ul><ul><ul><li>WSE’s implementation of WS-* </li></ul></ul><ul><ul><li>Where does WSE Fit in the MS stack </li></ul></ul><ul><li>Solution Implementation: Case Study using WSE </li></ul><ul><ul><li>Goals & Requirements Defined </li></ul></ul><ul><ul><li>Overall Architecture </li></ul></ul><ul><ul><li>Security Concerns & Design Process </li></ul></ul><ul><ul><li>Communication Use Case scenarios </li></ul></ul><ul><li>Q&A </li></ul>
  3. 3. <ul><li>Saint Francis Heart Hospital </li></ul><ul><li>New Cardiac Care Acute Care Facility - 2004 </li></ul><ul><li>All Digital </li></ul><ul><ul><li>External paper scanned </li></ul></ul><ul><ul><li>Internal : bedside EMR </li></ul></ul><ul><ul><li>CPOE, Med Management </li></ul></ul><ul><ul><li>PACS for images, Bedside devices integrated </li></ul></ul><ul><li>Comprehensive rollout (OR, ICU, ED, Gen Floors) </li></ul><ul><li>Inpatient solution from Vendor A (GE Healthcare) </li></ul><ul><li>Cardiology Of Tulsa </li></ul><ul><li>30 Year old established cardiology group with 20 cardiologists </li></ul><ul><li>All Digital </li></ul><ul><ul><li>Physician H&P </li></ul></ul><ul><ul><li>Nurse/Tech Notes </li></ul></ul><ul><ul><li>Dx Studies </li></ul></ul><ul><li>Comprehensive rollout within ambulatory Care </li></ul><ul><li>Ambulatory Care solution from Vendor B (NexGen) </li></ul>
  4. 4. <ul><li>Saint Francis Heart Hospital </li></ul><ul><li>New Cardiac Care Acute Care Facility - 2004 </li></ul><ul><li>All Digital </li></ul><ul><ul><li>External paper scanned </li></ul></ul><ul><ul><li>Internal : bedside EMR </li></ul></ul><ul><ul><li>CPOE, Med Management </li></ul></ul><ul><ul><li>PACS for images, Bedside devices integrated </li></ul></ul><ul><li>Comprehensive rollout (OR, ICU, ED, Gen Floors) </li></ul><ul><li>Inpatient solution from Vendor A (GE Healthcare) </li></ul><ul><li>Cardiology Of Tulsa </li></ul><ul><li>30 Year old established cardiology group with 20 cardiologists </li></ul><ul><li>All Digital </li></ul><ul><ul><li>Physician H&P </li></ul></ul><ul><ul><li>Nurse/Tech Notes </li></ul></ul><ul><ul><li>Dx Studies </li></ul></ul><ul><li>Comprehensive rollout within ambulatory Care </li></ul><ul><li>Ambulatory Care solution from Vendor B (NexGen) </li></ul><ul><li>Two Digital Islands with Humans Serving as Bridge </li></ul><ul><ul><li>>50% of admissions at SFHH come from COT </li></ul></ul><ul><ul><li>Ambulatory EMR printouts scanned into Inpatient EMR for every patient ! </li></ul></ul><ul><ul><li>No data continuity </li></ul></ul><ul><ul><li>Human intervention for each encounter </li></ul></ul><ul><ul><li>Expensive and error prone </li></ul></ul><ul><li>We needed a LHIO (local health information org) </li></ul>
  5. 5. <ul><li>Saint Francis Heart Hospital </li></ul><ul><li>New Cardiac Care Acute Care Facility - 2004 </li></ul><ul><li>All Digital </li></ul><ul><ul><li>External paper scanned </li></ul></ul><ul><ul><li>Internal : bedside EMR </li></ul></ul><ul><ul><li>CPOE, Med Management </li></ul></ul><ul><ul><li>PACS for images, Bedside devices integrated </li></ul></ul><ul><li>Comprehensive rollout (OR, ICU, ED, Gen Floors) </li></ul><ul><li>Inpatient solution from Vendor A (GE Healthcare) </li></ul><ul><li>Cardiology Of Tulsa </li></ul><ul><li>30 Year old established cardiology group with 20 cardiologists </li></ul><ul><li>All Digital </li></ul><ul><ul><li>Physician H&P </li></ul></ul><ul><ul><li>Nurse/Tech Notes </li></ul></ul><ul><ul><li>Dx Studies </li></ul></ul><ul><li>Comprehensive rollout within ambulatory Care </li></ul><ul><li>Ambulatory Care solution from Vendor B (NexGen) </li></ul><ul><li>Our LHIO had all the trappings of a RHIO except the organizational, structural, political obstacles to getting started. </li></ul><ul><ul><li>No common patient identifier </li></ul></ul><ul><ul><li>No common technology platform </li></ul></ul><ul><ul><li>No common lexicon/dictionary </li></ul></ul><ul><li>Still had to contend with all privacy, confidentiality issues </li></ul><ul><ul><li>Distinct legal entities </li></ul></ul><ul><ul><li>Need to know basis for information sharing – JIT (just in time) </li></ul></ul><ul><li>Wanted to insure that technology infrastructure used in our LHIO scaled to the region </li></ul><ul><ul><li>Federated architecture </li></ul></ul><ul><ul><li>Sophisticated algorithm for patient matching </li></ul></ul><ul><ul><li>Security/authentication infrastructure </li></ul></ul><ul><ul><li>Use the web for communication infrastructure </li></ul></ul>
  6. 6. Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li></ul><ul><ul><li>The WS-* specifications </li></ul></ul><ul><ul><li>WSE defined </li></ul></ul><ul><ul><li>WSE’s implementation of WS-* </li></ul></ul><ul><ul><li>Where does WSE Fit in the MS stack </li></ul></ul><ul><li>Solution Implementation: Case Study using WSE </li></ul><ul><ul><li>Goals & Requirements Defined </li></ul></ul><ul><ul><li>Overall Architecture </li></ul></ul><ul><ul><li>Security Concerns & Design Process </li></ul></ul><ul><ul><li>Communication Use Case scenarios </li></ul></ul><ul><li>Q&A </li></ul>
  7. 7. Evolution of Distributed Systems <ul><li>Web Services </li></ul><ul><li>Open, Industry-Wide Standards </li></ul><ul><li>Service-Oriented </li></ul><ul><li>Designed for Hostile Networks </li></ul><ul><li>Standardized Xml Wire Protocols </li></ul><ul><li>Web-Services with WS-* protocol stack is the gold standard </li></ul><ul><li>Component Architectures </li></ul><ul><li>Closed/Proprietary Standards </li></ul><ul><li>Object-Oriented </li></ul><ul><li>Ill-Suited for Hostile Networks (i.e., Internet) </li></ul><ul><li>Standardized Binary Wire Protocols </li></ul><ul><li>Examples </li></ul><ul><ul><li>DCOM </li></ul></ul><ul><ul><li>.NET Remoting </li></ul></ul><ul><ul><li>CORBA </li></ul></ul><ul><ul><li>Java RMI </li></ul></ul><ul><li>Socket Messaging </li></ul><ul><li>Ad-hoc application-level protocols </li></ul><ul><li>Message-Oriented </li></ul><ul><li>Usually required private networks </li></ul><ul><li>Custom Wire Protocols </li></ul><ul><li>Examples </li></ul><ul><ul><li>HL7 </li></ul></ul>TIME
  8. 8. The WS-* Specifications <ul><li>Defined </li></ul><ul><ul><li>A collection of standards that provide for secure, transacted, distributed messaging by extending the Simple Object Access Protocol (SOAP) </li></ul></ul><ul><li>Why they’re needed </li></ul><ul><ul><li>It’s a standard way for servers running different operating systems to communicate with one another between institutions over potentially hostile networks (like the internet) </li></ul></ul><ul><li>Development </li></ul><ul><ul><li>The standards body OASIS coordinates specification releases </li></ul></ul><ul><ul><li>Maturity </li></ul></ul><ul><ul><ul><li>First revisions released in 2002-2003 </li></ul></ul></ul><ul><ul><ul><li>Second revisions in 2004-2005 </li></ul></ul></ul><ul><li>Participants </li></ul>Microsoft Nokia Nortel Oracle RSA Security Sarvega SeeBeyond Sun Microsystems Systinet TIBCO Software US Navy Verisign (and more) Actional Adobe Systems AmberPoint Argonne National Laboratory BEA Systems BMC Software Computer Associates ContentGuard Cybertrust Cyclone Commerce Datapower EMC Forum Systems Fujitsu GeoTrust Hewlett-Packard Hitachi IBM Lockheed Martin
  9. 9. WS-* Specifications http://msdn.microsoft.com/webservices/webservices/understanding/specs/ XML Xml Namespaces Infoset Messaging SOAP WS-Addressing MTOM Security WS-Security WS-SecurityPolicy WS-SecureConversation WS-Security-Kerberos WS-Trust WS-Federation Reliable Messaging WS- Reliable Messaging WS-RM Policy Transactions WS- Coordination WS-Atomic Transaction WS-Business Activity Metadata XML Schema WSDL WS-Policy WS-Policy Assertions WS-Policy Attachment
  10. 10. WSE Defined <ul><li>Microsoft Web Service Enhancements </li></ul><ul><ul><li>A secure, distributed messaging framework that implements a subset of the WS-* standards </li></ul></ul><ul><ul><li>Extends existing web service .Net libraries (System.Web.Services) </li></ul></ul><ul><li>MS has boiled down very broad and inclusive WS-* standards into more concrete implementation choices </li></ul>
  11. 11. WSE 3.0 Coverage of WS-* XML Xml Namespaces Infoset Messaging SOAP WS-Addressing MTOM Security WS-Security WS-SecurityPolicy WS-SecureConversation WS-Security-Kerberos WS-Trust WS-Federation Reliable Messaging WS- Reliable Messaging WS-RM Policy Transactions WS- Coordination WS-Atomic Transaction WS-Business Activity Metadata XML Schema WSDL WS-Policy WS-Policy Assertions WS-Policy Attachment WSE 3.0 .Net Framework Will be in Indigo
  12. 12. WSE’s Place in the MS Stack <ul><li>Development </li></ul><ul><ul><li>Designed for .NET </li></ul></ul><ul><ul><ul><li>C# </li></ul></ul></ul><ul><ul><ul><li>VB.Net </li></ul></ul></ul><ul><ul><ul><li>Managed C++ </li></ul></ul></ul><ul><li>Hosting Environment </li></ul><ul><ul><li>Use IIS </li></ul></ul><ul><ul><li>Self-host (using the Windows service controller, for example) </li></ul></ul><ul><li>Installation </li></ul><ul><ul><li>WSE Runtime must be installed on each dev/test/production box </li></ul></ul><ul><li>Future Releases </li></ul><ul><ul><li>MS says WSE 3.0 is the final version </li></ul></ul><ul><ul><li>Longhorn will natively include WSE functionality in the Windows Communication Framework (WCF) </li></ul></ul>
  13. 13. Interoperability <ul><li>Primary MS Partners for WS-* are IBM and BEA </li></ul><ul><ul><li>Java will have enterprise-grade, commercial WS-* implementations that will interoperate with WSE/Indigo </li></ul></ul><ul><ul><ul><li>IBM WebSphere </li></ul></ul></ul><ul><ul><ul><li>BEA WebLogic </li></ul></ul></ul><ul><ul><li>Axis is the premiere open-source Web Services provider over Apache </li></ul></ul><ul><ul><ul><li>Does not support WS-Security et al, yet. Work still ongoing in this area </li></ul></ul></ul>
  14. 14. Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li></ul><ul><ul><li>The WS-* specifications </li></ul></ul><ul><ul><li>WSE defined </li></ul></ul><ul><ul><li>WSE’s implementation of WS-* </li></ul></ul><ul><ul><li>Where does WSE Fit in the MS stack </li></ul></ul><ul><li>Solution Implementation: Case Study using WSE </li></ul><ul><ul><li>Goals & Requirements Defined </li></ul></ul><ul><ul><li>Overall Architecture </li></ul></ul><ul><ul><li>Security Concerns & Design Process </li></ul></ul><ul><ul><li>Communication Use Case scenarios </li></ul></ul><ul><li>Q&A </li></ul>
  15. 15. System Goals <ul><li>The architecture should enable RHIOs to seamlessly share information </li></ul><ul><li>Support heterogeneous environments, many CDRs / EMRs from many vendors </li></ul><ul><li>Design as a Service Oriented Architecture (SOA) to logically and physically simplify the design </li></ul>
  16. 16. System Requirements <ul><li>Clinical data must pass directly from the sending institution to the receiving institution; no middle men </li></ul><ul><li>Aggregated demographic information must be one-way hashed to limit the index’s value to potential attackers </li></ul><ul><li>Individual institutions must have the last say regarding data transfer and maintain a local audit </li></ul><ul><li>It must be easy to add new sites to the network </li></ul><ul><li>Patients must be able to opt out </li></ul><ul><li>The system must scale up and down </li></ul><ul><li>Must operate securely over the internet </li></ul>
  17. 17. Top-level Architecture Blinded Record Index (BRI) … … Site B Adapter Site C Adapter Site A Adapter
  18. 18. Security Checklist <ul><li>Identity verification </li></ul><ul><li>Data confidentiality </li></ul><ul><li>Data origin </li></ul><ul><li>Message integrity </li></ul><ul><li>Protect against malformed or malicious messages </li></ul><ul><li>Shield exceptions from revealing sensitive implementation details </li></ul><ul><li>Replay protection </li></ul><ul><li>Generate audit logs </li></ul>
  19. 19. Design Process <ul><li>Define trust boundaries </li></ul><ul><li>Model threats </li></ul><ul><li>Design security solution </li></ul><ul><ul><li>Identify an authentication mechanism </li></ul></ul><ul><ul><li>Implement security policies </li></ul></ul><ul><ul><li>Additional security measures </li></ul></ul><ul><li>Verify threat coverage </li></ul>
  20. 20. Security Implementation Choices <ul><li>Authentication </li></ul><ul><ul><li>Direct </li></ul></ul><ul><ul><ul><li>Windows Authentication </li></ul></ul></ul><ul><ul><ul><li>Active Directory </li></ul></ul></ul><ul><ul><ul><li>Custom password file </li></ul></ul></ul><ul><ul><li>Brokered </li></ul></ul><ul><ul><ul><li>Kerberos </li></ul></ul></ul><ul><ul><ul><li>X.509 Public Key Infrastructure (PKI) </li></ul></ul></ul><ul><ul><ul><li>Security Token Service (STS) </li></ul></ul></ul><ul><li>Transmission Security </li></ul><ul><ul><li>Message Level </li></ul></ul><ul><ul><ul><li>Shared secret </li></ul></ul></ul><ul><ul><ul><li>Asymmetric encryption </li></ul></ul></ul><ul><ul><li>Transport Level </li></ul></ul><ul><ul><ul><li>SSL </li></ul></ul></ul><ul><ul><ul><li>VPN </li></ul></ul></ul><ul><ul><ul><ul><li>IPSec </li></ul></ul></ul></ul><ul><ul><ul><ul><li>PPtP </li></ul></ul></ul></ul>
  21. 21. Direct Authentication <ul><li>Benefits </li></ul><ul><ul><li>Simple </li></ul></ul><ul><ul><li>Compatible: It’s easy to leverage an existing password store </li></ul></ul><ul><ul><ul><li>Windows Auth </li></ul></ul></ul><ul><ul><ul><li>Active Directory </li></ul></ul></ul><ul><ul><ul><li>Custom password files </li></ul></ul></ul><ul><li>Liabilities </li></ul><ul><ul><li>No sessions: proof-of-possession must be sent each time which requires password caching </li></ul></ul><ul><ul><li>Home-cooked password files must be carefully secured </li></ul></ul><ul><ul><li>Direct trust: every actor must directly trust the others </li></ul></ul><ul><ul><li>Scales poorly: May result in many password files, each needing to be updated when a new user is added </li></ul></ul>
  22. 22. Kerberos Authentication <ul><li>Benefits </li></ul><ul><ul><li>Sessions: client need only authenticate once to interact with services many times </li></ul></ul><ul><ul><li>Single password file </li></ul></ul><ul><ul><li>Allows for impersonation / delegation </li></ul></ul><ul><li>Liabilities </li></ul><ul><ul><li>KDC may be a single point of failure </li></ul></ul><ul><ul><li>Requires Active Directory </li></ul></ul><ul><ul><li>Centralized nature makes it inappropriate for many cross-organization scenarios </li></ul></ul><ul><ul><li>Clocks must be synchronized </li></ul></ul>
  23. 23. X.509 Authentication <ul><li>Benefits </li></ul><ul><ul><li>Supports sessions </li></ul></ul><ul><ul><li>Broadly accepted: suitable for cross-organization authentication </li></ul></ul><ul><ul><li>There’s no password file to maintain; certificates are signed once to establish trust </li></ul></ul><ul><ul><li>May need a CA such as Windows Certificate Services </li></ul></ul><ul><li>Liabilities </li></ul><ul><ul><li>Higher one-time setup cost makes it suitable for architectures with relatively fewer actors </li></ul></ul><ul><ul><li>Must maintain a revocation list: certificate lifetime is a concern </li></ul></ul><ul><ul><li>Clients must be careful to protect their private key </li></ul></ul><ul><ul><li>Can be computationally expensive </li></ul></ul>
  24. 24. Security Token Service (STS) <ul><li>Benefits </li></ul><ul><ul><li>Can support cross-organization authentication </li></ul></ul><ul><ul><li>Most flexible option allows for heterogeneous environments including X.509, Kerberos and custom auth </li></ul></ul><ul><ul><li>Can enable web service federation </li></ul></ul><ul><li>Liabilities </li></ul><ul><ul><li>More work to implement </li></ul></ul><ul><ul><li>Requires a more thorough understanding of security implications </li></ul></ul><ul><ul><li>Requires the use of a separate encryption/signing mechanism </li></ul></ul>
  25. 25. Top-level Architecture Revised Blinded Record Index (BRI) … … Security Token Service (STS) Site B Adapter Site C Adapter Site A Adapter
  26. 26. Communication Scenarios <ul><li>Site sending data to BRI </li></ul>Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 Site A requests a security token and signs the message STS verifies the signature and issues the security token Site A sends a message to BRI signed with Site A’s cert and encrypted with BRI’s. 1 2 3 Site A Adapter Site B Adapter
  27. 27. Communication Scenarios Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 1 2 3 BRI requests a security token and signs the message STS verifies the signature and issues the security token BRI sends a message to Site A signed with BRI’s cert and encrypted with Site A’s. Site receiving data from BRI Site A Adapter Site B Adapter
  28. 28. Communication Scenarios Blinded Record Index (BRI) Security Token Service (STS) 1 2 3 1 2 3 Site A requests a security token and signs the message STS verifies the signature and issues the security token Site A sends a message to Site B signed with A’s cert and encrypted with B’s. Sites requesting data from each other Site A Adapter Site B Adapter
  29. 29. Communication Scenarios Security Token Service (STS) 3 1 1 2 3 Administrator provides new site information STS generates a key pair and signs a certificate for the new site Administrator securely transfers the private key and certificate to the new site Administrator New site coming online Microsoft Certificate Services 2
  30. 30. Security Checklist <ul><li>Identity verification </li></ul><ul><li>Data confidentiality </li></ul><ul><li>Data origin </li></ul><ul><li>Message integrity </li></ul><ul><li>Protect against malformed or malicious messages </li></ul><ul><li>Shield exceptions from revealing sensitive implementation details </li></ul><ul><li>Replay protection </li></ul><ul><li>Generate audit logs </li></ul> X.509 Signing & Encryption  WSE & .Net Framework  WSE custom assertion  Custom implementation          Not addressed
  31. 31. Adapter Architecture Host System Adapter Internal Network Local Data Service Clinical Data Service Data Transfer Service Index Service Perimeter Service Router Audit DB Local Index
  32. 32. Communication Scenarios Internal Network External Communication Perimeter Service Router Audit DB 1 2 Data Transfer Service Index Service 1 BRI has sends index information to the Adapter 2 The Service Router authenticates the request and forwards it
  33. 33. Communication Scenarios Service-to-Service Communication 1 Send message signed by service account with Windows Authentication Internal Network Local Data Service Clinical Data Service Data Transfer Service Index Service Local Index 1
  34. 34. Security Checklist <ul><li>Identity verification </li></ul><ul><li>Data confidentiality </li></ul><ul><li>Data origin </li></ul><ul><li>Message integrity </li></ul><ul><li>Protect against malformed or malicious messages </li></ul><ul><li>Shield exceptions from revealing sensitive implementation details </li></ul><ul><li>Replay protection </li></ul><ul><li>Generate audit logs </li></ul> X.509 Signing & Encryption  WSE & .Net Framework  WSE custom assertion  Custom implementation      Not addressed    
  35. 35. In Summary <ul><li>RHIOs require </li></ul><ul><ul><li>High security </li></ul></ul><ul><ul><li>Solid interoperability </li></ul></ul><ul><li>WSE 3.0 offers </li></ul><ul><ul><li>Powerful libraries to enable complex RHIO scenarios </li></ul></ul><ul><ul><li>Security features that are flexible and configurable </li></ul></ul><ul><ul><li>Interoperability that is key to guaranteeing the long term viability of the solution </li></ul></ul>
  36. 36. Agenda <ul><li>Statement of the Problem </li></ul><ul><li>Solution Defined – Intro to Web Service Enhancements (WSE ) </li></ul><ul><ul><li>The WS-* specifications </li></ul></ul><ul><ul><li>WSE defined </li></ul></ul><ul><ul><li>WSE’s implementation of WS-* </li></ul></ul><ul><ul><li>Where does WSE Fit in the MS stack </li></ul></ul><ul><li>Solution Implementation: Case Study using WSE </li></ul><ul><ul><li>Goals & Requirements Defined </li></ul></ul><ul><ul><li>Overall Architecture </li></ul></ul><ul><ul><li>Security Concerns & Design Process </li></ul></ul><ul><ul><li>Communication Use Case scenarios </li></ul></ul><ul><li>Q&A </li></ul>

×