Over in the comments for Tim Bray’s “S for Simple” post and again over on his personal blog, Gunnar Peterson claims that the standard REST security approach is inadequate and that something like WS-Security is required for any truly secure architecture. Gunnar has a shoot-from-the-hip tone, but we’ve communicated briefly via email and he states that he would like to buy into the REST vision if only security was adequately addressed. So lets compare and contrast approaches.
The standard RESTful security approach is, of course, HTTP Basic or HTTP Digest or SSL certificate-based mutual authentication for propagating identity credentials (the actual act of authentication and authorization being the purview of the server) and SSL for data integrity (digital signatures) and data protection (encryption). Gunnar notes that these technologies were state of the art in 1995, with the implication they are no longer sufficient for meeting the security needs of the 21st century. This is an example of what I call the “Gilligan, you can’t fly” argument; that is stating that something can’t be done even as somebody else is doing it. The fact is that billions of dollars of worth of business is conducted every year
over because of SSL.
SSL has shown itself to be amazingly versatile. Not only do I do my online banking and shopping over SSL, I VPN into the office over SSL and check and send email over SSL. That the first version of SSL is now some 11 years old is a boon. In fact, that’s exactly what I want in a standard; stability for the long term. More so in a security related standard, as that provides the time to shake out any bugs and ambiguities. Of course, SSL hasn’t been static; there’s been SSL 2, and SSL 3, and now TLS 1.1. In fact, given the relative youth of WS-Security, what do you think the odds are that it is immune to attack and that all of the implementations are free from bugs? Close to zero I would imagine. That’s not a slam on WSS–all standards are young once–but praise for the tried and true.
Gunnar notes that the world has moved past SSL etc., and cites as examples identity theft, phishing/pharming, and malware. But these security threats are completely orhtogonal to the security concerns SSL addresses. Ditto, I might add, WS-Security. Both of these standards address identity propagation, message encryption, and message integrity only, and neither will protect you from the threats just mentioned. Security is a BIG subject and the areas covered by SSL and WS-Security are just one small part of it. We also need good practices around securing persisted data (and what data to persist); education to prevent social engineering attacks; properly designed operating systems that won’t run anything with a .exe extension or run needless services; developers who are cognizant of buffer overflows, SQL injection, and cross-site scripting attacks; properly managed perimeter defenses; and so on and so on.
Gunnar then notes that HTTP Basic is not secure, and that, of course, is absolutely true. The password passed via HTTP Basic is base64 encoded, which is practically the same thing as being sent in clear text. In fact, it is the same thing, as encoding is not encryption. However, nobody is claiming otherwise. For those use cases where identity is all that’s required, then HTTP Basic is all that’s needed. For the larger number of use cases where credentials need to be encrypted, then use HTTP Basic in conjunction with SSL or use HTTP Digest or use SSL mutual auth. I’ll note that WSS is similar in design. The standard identity token is the Username token, the password element of which is sent in the clear by default. You can hash the password, but it should be noted that the recommendations specified in the Username Token Profile require that the server store the user’s password in clear text. Avoiding this requires an out-of-band negotiation that cannot be specified using WS-SecurityPolicy.
Gunnar next takes SSL to task for providing a great big hole through the firewall. I have to confess that I don’t understand this point. Sure, SSL encrypts the content of the communication channel, but that’s what it’s supposed to do, and, as already noted, it seems to work pretty well. Furthermore, when using HTTPS, communication travels through a completely different port than HTTP. A port that can be monitored more carefully. With WSS, not only do we have SOAP tunneling over HTTP, we have encrypted messages in the SOAP envelope. I don’t see how that could be better. In fact, the SOAP tunneling alone is a fairly significant security hole. Requiring that companies invest in new infrastructure to secure against threats that bypasses all the stuff they’ve already deployed. Furthermore, it’s not like the SSL connection is being terminated on the application server, more likely than not there is some intermediary up front that terminates the session, e.g. an SSL accelerator or proxy server. And before you can say, “ah hah,” know that the same is true for WSS. A properly architected SOA security solution addresses security concerns in “the cloud” using either an XML gateway or a web services management solution. (An article I wrote on this subject goes into more detail.) In other words, done right, the message received by a WSS-secured endpoint is also in the clear.
Gunnar goes on to note that the point-to-point security offered by SSL is an interoperability and simplicity nightmare. I don’t get this point either. Not only is SSL well understood, broadly implemented, and properly constrained, it is quite evidently not an impediment to interoperability as I can securely connect to anyone on the planet right now, so long as they let me. In contrast, not only is SOAP well known for its continuing interoperability headaches, they show up in spades with WSS. Just for starters, how do I know that a SOAP endpoint is secured in any way? You can’t tell from the URL and there’s no handshake with which client and server can negotiate security. If a service is secure, in what way? Do I need to provide credentials? What kind? A Username token? (hashed?) A SAML token? (how much of SAML do you support?) Or an encoded certificate? Is encryption used? The whole message or just some elements? Do I need to sign it? You can say that all of this is addressed by WS-SecurityPolicy, but WS-SecurityPolicy isn’t baked yet nor is anyone using it. And, as we’ve just shown, it’s not comprehensive. Furthermore, we have the implementation details. Is, say, BEA’s WSS implementation really 100% compatible with Microsoft’s, and is that 100% compatible with IBM’s, and is that 100% compatible with AmberPoint’s, and so on down the line. I don’t know the answer to this (since there doesn’t seem to be any instances of WSS encryption/DSig use in the wild [read the comments too]), but I strongly suspect not. To demonstrate, please retrieve this encrypted representation of a common greeting. Now, I don’t know what browser you’re using (if any) or what OS or anything. And you don’t know what encryption algorithm I’m using or what version of SSL etc. However, even though we have no a priori information about each other, I am absolutely positive that you were able to retrieve that resource. What can be simpler than that?
With all of that behind us, I can get on to what seems to be Gunnar’s main point and the only significant difference (outside of the whole simplicity and interoperability thing) between SSL and WS-Security. And that is that SSL provides transport level, point-to-point security while WSS provides message level, end-to-end security. That’s true, but that doesn’t provide WSS with magical security powers, it just solves a different problem. Nor does it relegate SSL to the scrap heap of history. SSL is not a security panacea–nothing is, but it does what it is does very well. Regardless, there is nothing in REST that prohibits the use of message-level encryption, though the mechanism–should it be needed–would need to be spec’d out.
I’m not dismissing WSS, it’s a perfectly adequate specification for what it does (though it requires the WS-I Security Profile to introduce enough constraints to provide a reasonable chance of interoperability). But the value of message level security should still be questioned. For one thing, what’s the business case? If message-level encryption is so important, why isn’t anyone using it? When Burton Group queried its clients as to their use of WSS, it was found that the only use was to pass identity tokens over HTTPS. When I was working at Systinet (now HP) I vividly recall the WASP (not Systinet Server for Java) product manager spitting nails because his team had just spent six months implementing WSS at our customer’s request and no one–not even those who requested the feature–was using it. Also, this is not the first time message level security has been proposed. When I was working at Netscape back in 1997 I spent a fair amount of my time advocating for S/MIME. Now, nearly ten years later, how many people are using S/MIME to secure their email? And how many are using SSL? Exactly.
In summary, RESTful security, that is SSL and HTTP Basic/Digest, provides a stable and mature solution that addresses transport level credential passing, encryption, and integrity. It is ubiquitous, simple, and interoperable. It requires no out-of-band contract negotiation or a priori knowledge of how the resource (okay, service) is secured. It leverages your existing security infrastructure and expertise. And it addresses 99% of the use cases you are likely to encounter. SSL does not support message level security, and if that’s a requirement, then leveraging SOAP and WSS makes sense. Recall, though, that this is not a limitation of REST per se, though it is left as an exercise to the reader. SSL is not perfect and it does not address all security requirements, but nothing does or can.
Hope that helps.