Using the Filter Proxy

Using the Filter Proxy

The Filter Proxy is a Toolkit simulator that filters the request and/or response of the messages that pass through it. It is called a Proxy since it always filters content for another system, referred to below as the System Under Test (SUT).

Filters

It currently contains a single filter that repairs SOAP headers that employ some advanced security headers. Toolkit uses the Axis2 SOAP library which depends on the Axiom SOAP parser/handler. This filter manipulates the XML in the SOAP header to work around a bug in Axiom.

The example we developed the filter from is shown in this example.

General operation

When the Filter Proxy is needed these general steps are followed to install and configure it.

1. Configure the System Under Test (SUT) as a system in Toolkit.

2. Create a Filter Proxy simulator.

3. Configure the Filter Proxy simulator to front for the SUT.

4. To test the SUT, point the Conformance Tool at the Proxy which forwards to the SUT.

Specific Operation

The actual configuration steps are easier than the general description implies.

1. Configure the System Under Test (SUT) as a system in Toolkit.

2. At the bottom of the System Configuration editor is a check box labeled Enable Filter Proxy. When the configuration is saved (Save Changes button) with this box checked, the Filter Proxy is generated and configured automatically.

3. If the SUT configuration is edited, the Filter Proxy is updated.

4. If the SUT configuration is deleted, the Filter Proxy is deleted.

5. If the Enable Filter Proxy box is unchecked, the Filter Proxy is deleted.

If you check the Show Sims box you can observe this operation.

Naming conventions

The generation of the Filter Proxy follows some simple naming conventions. If the SUT system is named sut and the Test Session is default then the Filter Proxy will be named default__sut_filterproxy. In this tool, when the display of simulators is enabled, they are displayed with the Test Session name prefix (so the default__ prefix is shown at front of the name). By convention the Filter Proxy for system sut is named sut_filterproxy (so the suffix).

Test and Tool operation

The Conformance Tool and other more general tools operate without concern if you choose the system wisely (with a nod to the knights of the round table). Selecting sut from the above example will send directly to the configured system. Selecting sut__filterproxy will send through the Filter Proxy. Again, choose wisely Indiana Jones.

Examining the Filter Proxy simulator

If you examine the generated Filter Proxy simulator you will observe:

1. The V2 Patient Identity Feed port is the same (as the SUT).

2. The homeCommunityId is the same.

3. The normal endpoints (for the Register transaction for example) point to the Filter Proxy simulator.

4. There are a new set of endpoints whose names are the normal endpoint names with a prefix of *Relay To.

5. When you send to the simulator, Toolkit picks up the normal endpoints (which point to the Filter Proxy). As the simulator operates, it uses the Relay To endpoints to reference the system behind the proxy.

Configuration

Like the normal internal HTTP Client, the Filter Proxy relies on some configuration in toolkit.properties. The properties that it is sensitive to are:

Client_SSL_Protocols - comma separated list of protocols. For Connectathon we use TLSv1.2

Client_Cipher_Suites - comma separated list of cipher suites. For Connectathon we use TLS_RSA_WITH_AES_128_CBC_SHA

Note - this client always validates IP addresses against host names (DNS or local host table) where the default client does not (see https://github.com/usnistgov/iheos-toolkit2/issues/493).