At the RSA Conference last week, I gave a talk on REST Security. I feel that REST is an area which is largely ignored when people talk about "Secure Web Services" [I talked in the Secure Web Services track at RSA]. People tend to forget that REST has a lot of the practical Web Services traction, with SOAP gradually taking off but not yet having the same amount of usage as REST.
I began the talk by stating that REST in practice is a lot different from REST in theory. This is very important from a security point of view. I talked a lot about the theoretical underpinnings of REST, in particular the core point that HTTP should not be re-invented at the SOAP "layer". Roy Fielding and Paul Prescod's writings were, of course, very influential on me, and both get mentions in the talk. The theoretical aspect of REST states that you use the HTTP "verbs", GET and POST and UPDATE and DELETE, rather than doing everything via SOAP POSTs. I give the example of a weather information service [something that I hoped would resonate with many of the RSA conference delegates, who faced weather challenges in even getting to RSA at all]. My example was "ivory tower" REST, where I was using the HTTP methods as they are intended.
But, then I reminded the audience that REST in practice is different from REST in theory. The part of REST that is really being widely used is the ability to interact with Web Services using HTTP GETs. It reminds me of how PKI is very theory-heavy and quite complicated, but a relatively small slice of it really found general usage, for SSL [i.e. PKI without OCSP, without CRL checking, without signing of data, without even checking identities properly in some cases ].
This means that when people talk about a "REST style" Web Service, they usually mean a Web Service that presents a HTTP GET interface. This is very different from the original intent of REST, where GETs are only supposed to be used for fetching information, not for changing server state. Some people, such as Dare Obasanjo from Microsoft, have pointed out the fact that Websites that claim a "REST" interface can have interfaces that actually break the REST model.
After talking about the theory of REST, and comparing it with the practice, I then talked about how security applies to REST. Now, if you are talking about "pure" REST, where a GET doesn't change state but a POST does, then you can apply ACLs to the REST methods [e.g. allow GETs from anyone, but block POSTs except from a group of trusted users]. Unfortunately, because in practice REST uses GETs extensively, that would be a naive approach. You'd have to trust your developers were developing "pure" REST services. Any security model that includes the three words "trust your developers" isn't going to fly.
So, then talked about how some of the concepts of Web Application Security and Web Services Security apply to "practical" HTTP GET style REST. Vordel has a lot of functionality in that area. We filter HTTP GET variables, as well as filtering SOAP methods and SOAP attachments, so that means that we protect both SOAP and REST style Web Services. In many cases, a REST interface is automatically generated when you develop a SOAP Web Service [Jason Hogg from Microsoft pointed out that you can turn this functionality off in Visual Studio .NET]. Vordel's competitors who only filter XML cannot protect "HTTP GET style" REST Web Services, which is by far the largest percentage of Web Services. That means that if you use a pure "XML Firewall" approach to protecting your Web Services, looking for incoming XML traffic, then REST traffic sails right through your security defenses. But not with Vordel, since we support REST.
For the last 15 minutes of the talk I looked at some of the "developer token" security models for REST Web Services, in particular those offered by Amazon and Google. Amazon's model is the most sophisticated, using a private "shared secret" token that is used for HMAC signing to show proof-of-possession of a "public" token that is sent to Amazon in REST invocations. This seems to me to be reinventing many of the features that are offered by WS-Security. If REST advocates criticise SOAP for reinventing the HTTP wheel, then I think that Amazon can be criticised here for reinventing the WS-Security wheel, not to mention the WS-I basic security guidelines.
How widely used is REST? I used the old (2003) slide from Jeff Barr in Amazon, who pointed out that only 15% of Amazon Web Services traffic is SOAP based, and [here comes the pun] the rest is REST. I'd be very condident that gap has narrowed. It's much easier now to develop SOAP-based Web services, due to tools such as Visual Studio .NET etc. But REST is still very popular. I hope I've caused some debate on this. I think REST has been the elephant in the room when you talk about Web Services security, so now maybe the elephant is acknowledged [co-incidentally the first slide of my slide deck is an elephant, and there is an elephant on each page].
Here is a PDF slidedeck of my REST Security Presentation from RSA 2006 .
4:32:28 PM 
|
|
