OHI Webservices Access for External Client

It may be required to give external clients, that are not inside the company firewall, access to OHI web services. In that case, the following aspects have to be taken into account:

  • Do not expose the OHI web services directly, always make sure that the web services are fronted by a separate web server / load balancer.

  • Messages exchanged between a web service and an external client may contain protected health information; as a minimum security requirement, message traffic must be accessed only through HTTP secured with SSL.

  • Apply proper web services security policies to enforce authentication and to guarantee integrity and confidentiality of messages.

Validate OHI Web Service Requests

OHI Web Services come in two flavors:

  1. SOAP based. The message format is described in an XSD. The XSD can be used by the OHI application to validate the incoming message.

  2. REST based: There is no formal definition that can be used to validate incoming messages against.

OHI Web Services are designed and optimized to process "normal" requests. They may or may not be able to handle "invalid", or "malicious" requests. For example, many Web Services support the processing of an object including its children, where a moderate number of children is assumed. See this XSD snippet from the Claims In Integration point:

<xsd:element name="claimLines">
    <xsd:complexType>
        <xsd:sequence>
            <xsd:element ref="claimLine" maxOccurs="500"/>
        </xsd:sequence>
    </xsd:complexType>
</xsd:element>

The value "500" indicates that many claim lines can be included in a single claim. How many claim lines actually can be processed depends on the hardware and configuration in the customer configuration. During integration testing one need to find out what is possible in a given setup.

The Claims In Integration Point is not designed to handle a claim with 1.000.000 claim lines. A hacker might send in such a claim to bring the system down. It is therefore essential to validate incoming request before presenting them to the OHI application. The OHI application cannot do that validation:

  • REST Integration Points do not support this kind of payload validation.

  • SOAP based Integration Points do support validation of the XML payload against an XSD, but this validation is not meant to detect malicious requests. In order to do the validation, the malicious request must be loaded into memory, which might cause an out-of-memory right away.

When OHI Web Services are exposed to external clients, it is therefore essential to implement a Web Application Firewall and configure rules to detect and handle malicious requests. Only valid requests should be forwarded by the Web Application Firewell to the OHI application.

An example of a Web Application Firewall is Oracle Traffic Director.