An XMPP (Extensible Message and Presence Protocol) based implementation for NHIN Direct 1

An XMPP (Extensible Message and Presence Protocol) based implementation for NHIN Direct

1

Agenda

» Overview• NHIN Direct and XMPP • Why XMPP ?

» Mapping of the Abstract Model to XMPP implementation

» Security Model of the XMPP implementation

» XMPP implementation of the Content Container

» HIE Interoperability using XMPP

» Q & A / Demo

Overview

3

» NHIN Direct project will develop standards and services, which will allow organizations to deliver simple, direct, secure and scalable transport of health information over the Internet between known participants in support of Stage 1 meaningful use.

» XMPP protocol provides capabilities that allows realization of the NHIN Direct.• Simple – Built on Internet and DNS, Many open source libraries to implement

applications, user interfaces and integrate with existing systems and workflows.

• Direct – Realized using asynchronous message delivery, along with a publish-subscribe mechanism for specific events.

• Secure – Realized using TLS channel encryption, SASL authentication and authorization mechanisms, and extensive support for X509 based PKI infrastructure.

• Scalable – Realized using direct “Server Federation”, Clustering features of XMPP servers, A single XMPP server can support 1000’s of end points.

Overview Cont’d – Why XMPP

4

» As explained in the previous slide the XMPP protocol supports all the basic capabilities required to meet NHIN Direct goals.

» In addition, XMPP can serve as the “Innovation Platform” providing capabilities for HISP’s to innovate and create the next generation healthcare applications using:

• Presence features• Direct Server to Server federation, no intermediaries thus reducing the

probability of attack on the internet.• Out of band File Transfer features• Service Discovery and negotiation features• Publish-Subscribe services• Collaboration services• Protocol binding support for HTTP/S, SOAP etc.• Real time communication features.

Abstract Model Mapping to XMPP Implementation

5

XMPP Client A(Source/Destination)

XMPPServer1.com(Source HISP)

XMPPServer2.com(Destination HISP)

XMPP Client B(Destination)

Internet InternetInternet

Send and Receive Messages


Clients registered with XMPPServer2.com, which provides the NHIN Direct HISP services to its client B



Clients registered with XMPPServer1.com, which provides the NHIN Direct HISP services to its client A

DNS SystemsDNS SRV Lookup DNS SRV Lookup

DNS SystemsDNS Lookups

» NHIN Direct Backbone ProtocolXMPP over TLS.

» NHIN Direct HISP Address Directory• The servers, and end points are discovered using DNS directories

and DNS SRV lookups.

Abstract Model Mapping to XMPP Implementation Cont’d

6

» NHIN Direct Address• XMPP uses addresses which are similar to email addresses• Addresses come in two formats called the short address and the full address.

– The short address is of the format user@domain.– The full address is of the format user@domain/resource.

• For most practical applications the short address is sufficient.

» NHIN Direct Message• Mime Message carrying different payloads like xml data, documents and binary data

wrapped in XMPP xml tags. The Mime Message can be signed and encrypted using PKI infrastructure.

» NHIN Direct Source/Destination Edge Protocol• XMPP provides flexible options for deployment and can interface with various

protocols based on the deployment architecture.• The following are the most widely used options for deployment.

– XMPP with TLS. (Using standard XMPP ports).– XMPP over HTTP (HTTPS).

Security Model of the XMPP Implementation

7



TLS Channel+

Signed payload +

Encrypted payload

SASL Authentication of client to Server



SASL Authentication of client to Server

TLS Channel+

Signed payload +

Encrypted payload

TLS Channel+

Signed payload +

Encrypted payload

Channel Security:» The client to server communication (Source/Destination to HISP) is

encrypted using TLS based on X509 server certificates.

» The clients are authenticated to the server using SASL mechanisms. • SASL PLAIN uses (user + pwd)• SASL External supports client certificates.

» The Server to Server communication will be encrypted using TLS.

» The Server to Server authentication/authorization is performed using SASL External mechanism. (X509 certificates)

Security Model of the XMPP Implementation Cont’d

8

Certificate Support:» Client Certificates are distinct from server certificates

• Client certificates can be at the individual level or at the organization level

» Server Certificates are distinct from client certificates

» Allows certificate chains and/or anchors for certificate validation.

» Allows certificate revocation using OSCP and/or locally cached CRL’s.

» Payload Signing and Encryption will be accomplished using NHIN-D JAgent.

Content Container Implementation

9

Content Package Metadata» XMPP uses “To”, and “From” to route the message from source to

destination.» Header information as it is currently specified is sufficient for routing

between HISP’s.

Payload: » All attributes that are not part of the Header information are being packaged as

part of the payload.

» Once the Content Manifest is finalized and agreed upon, the XMPP implementation can be enhanced to support the required additional data.

• Note: This could inhibit adoption if the data is required to be entered manually vs being extracted from other payload information.

HIE Interoperability

10


XMPPServer.com(Source/Destination

HISP)

XMPP Client B(Destination)Internet Internet

Send and Receive Messages using XMPP


Scenario1: Source and Destination belong to the same HIO









Scenario2: Source and Destination belong to different HIO’s but both HIO’s support NHIN Direct XMPP Implementation




HIE Interoperability Cont’d

11

XMPPServer.com(HISP)

Regular NHIN Direct HISP Services

Source HIO Proxy Services

Destination HIO Proxy Services

NHIN Exchange Services

XMPP Client A(Source)


Internet

Source Without a HIO

Destination Without a HIO

NHIN Exchange Gateways




Send and Receive Messages using SOAP

Scenario3: HISP provides services for Source and Destination’s without HIO’s and services for Interaction with NHIN Exchange Gateways

Scenario4: Interacting with existing EHR/EMR systems

Prototype Instantiation and Configuration

12








Clients registered with XMPPServer2.com, which provides the NHIN Direct HISP services to its client B



Clients registered with XMPPServer1.com, which provides the NHIN Direct HISP services to its client A



Server Application(HISP)

Open Fire XMPP Server

MySQLDB

OpenLDAPDirectory

LDAP

JDBC

Client Application

JavaApplication

Smack XMPP Client

Library

Eclipse + JDK Libraries

Current Status of Prototype

13

» Establish XMPP servers in the cloud

» Basic Client / Server and Server to Server Messaging Infrastructure in place.

» Secure TLS Channels established between client and Servers, and Server to Servers

• Certificates from StartSSL were created and used with the prototype.

» Directory Integration for user account management with LDAP

» Simple User Interface to interact with the XMPP implementation and for account provisioning.

» Ongoing Activities: (Not completed)• Signing and Encrypting the MIME Message.• Proof of concept for Interoperability between NHIN Exchange and NHIN Direct.• Creating production level architecture and design documents.

Q & A

14

Documents

An XMPP (Extensible Message and Presence Protocol) based implementation for NHIN Direct 1