| Table of Contents |
|---|
| Info | ||
|---|---|---|
| ||
The ability to download, store and process data from multiple healthcare provider directories and the proof of concept to authenticate with multiple certificates on one CONNECT instance have been completed with the release of CONNECT 5.3. However, the messaging and SAML services are still strictly intended for NwHIN exchange. Additional code enhancements are required for complete multi-exchange implementation. |
Overview
Initial support for multiple exchanges certificates has been determined and implemented. CONNECT is currently capable of supporting multiple exchanges certificates from a directory perspective with its ability to download organizational data from any Fast Healthcare Interoperability Resources (FHIR) STU 3 compliant healthcare provider directory. Multi-exchange certificate, Transport Layer Security (TLS) and Security Assertion Markup Language (SAML) support extends the ability to support multiple exchanges with certificates on one CONNECT instance by providing the following:
...
| Requirement for SNI approach | Details |
|---|---|
| Wildfly 15 or higher | WildFly 15 supports server side SNI on its HTTPS listeners. This allows a WildFly instance listening on a single socket but with multiple virtual hosts associated with that listener to provide a different server certificate depending on what SNI name the client requests. For Wildfly 15 SNI configuration, refer to Multi-exchange certificate, TLS and SAML support#SNI configuration in Wildfly 15 . |
| WebSphere 8.5 or higher | Websphere 8 seems supporting SNI with its own IBM SDK. For more information, please see: https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.70.doc/security-component/whats_new/security_changes_70/security_whatsnew.html Multi-exchange support in Websphere Enterprise 8.5.5.3 |
| Other Application servers | Not all application servers have built-in SNI support. In order to reap benefits from multiple exchange feature of CONNECT, adopters can employ Apache server. See section 696615044 for details. |
Multiple
...
Certificates support with SNI
An assumption is made that CONNECT implementers participating in multiple exchanges will obtain separate SSL certificates for each exchange, thereby requiring the management of multiple private keysserver certificates. This requires CONNECT to understand which private key to associate server certificate use with which exchange. The certificate alias certificateAlias field in exchangeInfo.xml is used to load appropriate certificate for signing the SAML assertion. If there is no certificateAlias is defined in exchangeInfo.xml, CONNECT will pick the certificateAlias from system property CLIENT_KEY_ALIAS defined in server configuration.
...
An assumption is made that each exchange will incorporate the use of SNI and all participants of a single exchange are required to use the same domain value. It is also assumed that this domain value will be included in each exchange's directory.
CONNECT, will read the sniName (SNI) from exchangeInfo.xml file and initiates an SSL connection with the responding gateway. Based on SNI from initiating gateway, responding gateway will pick up the appropriate certificate to present for SSL handshake. After the SSL handshake is successful, its business as usual. If there are no SNI specified in exchangeInfo, CONNECT, as initiator, will not send the SNI during SSL handshake. At the responding gateway server, a default SNI needs to be defined in this case.
...
3.Based on <exchangeName> defined in entity request, CONNECT finds the <certificateAlias> to use to select the private key for signing the SAML assertion and XML header. CONNECT then sends a request with correct DN value in SAML assertion.
CONNECT as Responder
1.Server Server knows which certificate to present based on SNI value sent during client hello.
...
| Anchor | ||||
|---|---|---|---|---|
|
Adopters, when limited by their application server platform, can use Apache (proxy) server and multiple ports (binding each exchange to a unique port) to implement multiple-exchange feature. Initiating gateway will send the SNI during SSL handshake. The SSL handshake will happen between Initiating gateway and Apache (proxy) server. Once the handshake is successful, Apache (proxy) server will direct the request to appropriate port based on the SNI sent in SSL handshake.
Setup Details for Wildfly-8.2.1
...
When the the apache server receives traffic on port 443 with SNI of "ehex.org", it will present ehealth cert to initiator gateway... Once TLS handshake is successful, it will route message to port 8181(https) or 9191(https) depending on Apache's proxy configuration.
...