oehf / ipf-oht-atna Goto Github PK

Refactor ATNA Auditing.

The ATNA configuration has some properties to configure the TLS protocol (http://oehf.github.io/ipf/ipf-platform-camel-ihe/atna.html), e.g. https.protocols.

In my scenario I have force the ATNA server to only accept TLSv1.2 and configured https.protocols in my ATNA client to also use TLSv1.2.

As a result the TLS handshake was not possible.
If I enable network logging, i always see a "* ClientHello, TLSv1" instead of the expected "* ClientHello, TLSv1.2".

I expect that the issue is caused by:
org.openhealthtools.ihe.atna.nodeauth.handlers.TLSEnabledSocketHandler.createSecureSocket(String, int, SecurityDomain, Socket)

at least the line
socket.setEnabledProtocols(new String[] {"TLSv1"});
need to be rewritten to read the value from the securityDomain configuration, e.g.
socket.setEnabledProtocols(securityDomain.getEnabledProtocols()); //securityDomain need to be extended as well to expose the internal setting.

The original text of the HL7v3 Event Type Codes have no "V3"

see https://groups.google.com/forum/#!topic/ipf-user/PirJeQWGqf8

This is a follow-up issue to #5.
The new XML Schema for ATNA (https://ehealthsuisse.ihe-europe.net/xsd/EPD/ATNA/dicom_ihe_current.xsd) considers DICOM CP-1638, where the attribute //AuditSourceTypeCode/@code was renamed to @csd-code.

During connectathon testing, an issue was identified with IPF-OHT-ATNA 3.4.1 that ATNA over TLS is throwing the following configuration error if the ATNA server IP instead of the hostname is used:
org.openhealthtools.ihe.atna.nodeauth.NoSecurityDomainException: No DEFAULT Security Domain available for host ovh3.ihe-europe.net and port 10009 at org.openhealthtools.ihe.atna.nodeauth.SecurityDomainManager.getSecurityDomain(SecurityDomainManager.java:201) ~[ipf-oht-atna-nodeauth-3.4.1.jar:?] at org.openhealthtools.ihe.atna.nodeauth.handlers.AbstractSecureSocketHandler.getSocket(AbstractSecureSocketHandler.java:116) ~[ipf-oht-atna-nodeauth-3.4.1.jar:?] at org.openhealthtools.ihe.atna.auditor.sender.TLSSyslogSenderImpl.getTLSSocket(TLSSyslogSenderImpl.java:179) ~[ipf-oht-atna-auditor-3.4.1.jar:?] at org.openhealthtools.ihe.atna.auditor.sender.TLSSyslogSenderImpl.sendAuditEvent(TLSSyslogSenderImpl.java:140) ~[ipf-oht-atna-auditor-3.4.1.jar:?]

The simple workaround was using
audit.repository.host=HOSTNAME_OF_RECIPIENT
instead of
audit.repository.host=IP_OF_RECIPIENT

My first analyse on the issue:
In org.openhealthtools.ihe.atna.nodeauth.SecurityDomainManager.getSecurityDomain(String, int), there is an internal key created based on host and key. The map behind is filled with the initial values from the config file (so IP and Port). But during atna sending event, the method org.openhealthtools.ihe.atna.auditor.sender.TLSSyslogSenderImpl.getTLSSocket(InetAddress, int) perform a hostname resolvement "IP->Hostname" (destination.getHostName()) and the combination hostname + port could not be found in the map where only ip and port is present.

AuditSourceIdentificationType serializes its AuditSourceTypeCode attributes directly as attribute, but it should render inside a nested AuditSourceTypeCode element. Also, there can be more than one AuditSourceTypeCode.

see schema at http://dicom.nema.org/medical/dicom/current/output/html/part15.html#sect_A.5.1

I have configured ATNA as described in http://oehf.github.io/ipf/ipf-platform-camel-ihe/atna.html
especially using https.ciphersuites and https.protocols.

We have identified that ATNA TLS set this configuration as JVM system properties during startup, which has side effect on other interfaces as well. E.g. setting https.protocols = TLSv1 in the atna configuration will also reduce the supported TLS version on the HTTPs interface of the application server (TLSv1.2 will be rejected).

The underlying issue seems to be present in org.openhealthtools.ihe.atna.nodeauth.SecurityDomain.setOrClearSystemProperties(String, Properties) where the ATNA component call System.setProperty.

As a potential workaround, we programmatically set the current JVM defaults into this configuration, so it does not change the default behavior:
SSLParameters defaultSSLParameters = SSLContext.getDefault().getDefaultSSLParameters(); this.securityProperties.setProperty("https.ciphersuites", toCommaSeparatedString(defaultSSLParameters.getCipherSuites())); this.securityProperties.setProperty("https.protocols", toCommaSeparatedString(defaultSSLParameters.getProtocols()));

Any plans on supporting this element?

reference:
A.5 Audit Trail Message Format Profile

ITI-62 in the IHE RMD Supplement Rev 1.1 is the first place where this code is mandatory