The last mile

Fidel Santiago asked a great question in a comment on a previous blog post about XML Decryption.

The answer deserves a blog post of its own. So here it is!

Basically, the question is: When you do XML Decryption on an XML Gateway, what about the last mile?

It is a very good question. Taking a step back, let's remember that the advantages of doing XML Decryption on the XML Gateway are that:

(1) You are storing the private key in hardware (and not in a keystore on the file system as is the usual practice at a Web Service host),

(2) you get better performance than you would at the Web Service host, and:

(3) You can configure the XML Decryption based on a centralized policy, independent of the Web Service host.

But, you still have to think about the end-to-end security. Because you have to answer the question: "What about the connection from the XML Gateway to the Web Service host?".

You have a number of options for this. You can:

(a) Setup a mutually authenticated (and encrypted) SSL connection between the XML Gateway and the Web Service host. This has the advantage of being fast, even for an app server back-end which has no crypto acceleration card (hardware acceleration is only required for the session negotiation part of SSL, and once the session is established, it's fast). In this way, no attacker can connect directly to the Web Service, and the only client which can connect to the Web Service is the XML Gateway itself (which has the private key to authenticate, and it stores its private keys on hardware, so nobody can impersonate it). This is simple to configure on all Web Services platforms, and you have only one "user" (the XML Gateway) to manage. For example, I have set this architecture up myself in customers where the Vordel XML Gateway sits in front of SAP Netweaver.

Or you can:

(b) Run a software XML Gateway right on the Web Service host itself [i.e. at the "Last Mile"]. you still have to make sure that clients cannot just trivially connect to the Web Service directly.

Or, similarly:

(c) deploy an agent embedded into the Web Service endpoint host itself, at the last mile (such as the agents provided by Vordel's partners CA and Oracle). Agents are the classic solution for the last mile, and an alternative to using the host-based security in option (a) above.


It may be tempting to re-encrypt the XML at the data level at the XML Gateway and then decrypt it at the Web Service host. If you do this, you're falling into the traps of key management at the Web Service host (most app servers will just store the keys in a keystore file on the file system) and performance. The reason for re-encrypting at the XML Gateway would be to selectively encrypt part of the XML so that certain Web Services cannot see that data (e.g. "de-identitication" of medical records by removing patient IDs).