Thanks to Johannes Ernst for pointing out this gem by Peter Gutmann about the broken state of XML Security. Johannes is right – the article brings up a set of excellent points.
I often find myself asking the same question the original author Mr. Gutmann poses in his article – why insist on doing it the hard way? Within the context of web services, I’ve seen developers with little security training go down the road of WS-Security solutions that invariably break or are rendered useless by poor integration. Most often the project in question has three straightforward requirements:
The requirements are dead simple – but its so easy and tempting to get lost in the details of the XML-way-to-do-things that the obvious solution is never used. If you’re using SOAP for web services (which most people are), and you’re adhering to the WS-I Basic Profile 1.0 (which most people should be), then you’re using HTTP as a transport. The fact is that SSL/TLS provides a practical method of security communications between service providers and consumers over HTTP, including XML web services. It has practically universal platform support, good performance characteristics, encrypts all data sent between parties, prevents data tampering, supports authentication of both servers and clients, and there is widespread availability of acceleration hardware. Plus, the security is externalized, so it drastically reduces required integration time, and places no dependencies on developers for “proper” implementation. It’s a very pragmatic and elegant solution to several web service system security problems.
Don’t get me wrong. WSS is great and has a wide array of very legitimate uses, and I’m not downplaying its importance in the web service arena. Nor am I’m trying to imply that SSL/TLS is a security panacea – especially if your XML transport is not HTTP. But good system security is about choices – and often the simplest choice that meets a particular requirements is the best choice. So if your web service implementation has straightforward security requirements, my advice is to take a close hard look at SSL/TLS.
blog comments powered by Disqus