What comes in, and what goes out

Take a look at the diagram below of an XML Gateway at work. It is processing all input messages coming from the client to the Web Service, performing a wide range of functions (XML Enrichment, transformation, caching, authentication, authorization, XML threat detection). It looks pretty comprehensive. But what is missing from the picture?



The answer is: The response back from the Web Service.

It is easy to overlook the fact that an XML Gateway processes not only input to the Web Service, but the response from the Web Service also. Indeed, many deployment plans for XML Gateways ignore the processing of the response altogether. The thinking is "The input is coming from an untrusted client, so we have to process that. But, the response comes from our own systems so it is under our control, so we should just pass it unchanged back to the client".

So what should the XML Gateway do with the response?

1. Sign Responses for non-repudiation

It is often a good idea to sign messages which come back from a Web Service. This adds non-repudiation so that a client cannot claim to have gotten a different response a Web Service.

Let's look at how this is configured in the Vordel Policy Studio [this is our design-time policy creation and editing tool. If you don't have a copy, grab an evaluation]. In the Vordel Policy Studio, it is a simple matter to add response processing, by adding filters which follow routing filters (and therefore act on the response back from the Web Service). In the following screenshot we see a policy which is performing WS-Security UsernameToken authentication, input validation, XML Enrichment, then routing to a Web Service on WebLogic.



We can drag in a "Sign Message" filter (from the "Integrity" group on the right) and chain it after the filter which routes to the WebLogic Web Service. This means that the response back from WebLogic is signed by the XML Gateway before it is returned to the client.



Signing at the XML Gateway has a number of advantages over signing the response at the application server. For a start, the XML Gateway will use a key which is stored in hardware, rather than being stored in a software keystore on the file system of an application server. Also, in the case of Vordel's XML Gateways, it uses a patented XML acceleration subsystem (VXA) which results in significantly faster XML Signature processing than at an application server.

2. De-identification

"De-identification" means removing any identifying information from documents. For example, in healthcare, de-identification means removing patient information from a document such as a medical test result.

An XML Gateway is ideally positioned to perform de-identification, and by using XML Acceleration techniques it can perform this task without adding latency.

3. Data loss prevention

This means scanning the responses from Web Services to ensure that no information is leaking out which should not leak out. In the Vordel XML Gateway, you can define structures of confidential information and, if these structures are detected in the responses from Web Services, then the confidential information can be selectively encrypted, or simply stripped out of the messages.

4. Sanity Checking

If a Web Service normally returns back 5K of reponse data, but the XML Gateway detects that it has output a response of 50K to a particular query, then this indicates a red flag. It could be that the request has caused the Web Service to malfunction, compromising its functionality.

In addition, if a Web Service returns back a stack trace, or details of exceptions, then this should be sanitized by the XML Gateway rather than being passed back as-is to the client.

Schema validation of the response is also a good idea (but remember that Schemas alone are not useful for detecting harmful content) and run significantly faster on an XML Gateway than at an application server.

And last but not least:

5. Logging

Input messages are typically logged by an XML Gateway, and the same should go for responses. An XML Gateway can sign the logged messages as it logs them, in order to keep an evidential audit trail. It is important that XML Gateways contain hard drives so that they can perform on-board logging, rather than forcing traffic to be sent out to a remote logging destination (adding extra latency per message).


Putting it all together, we have:



i.e. both the input and the response are processed by the XML Gateway