SOAP and the mega-Services
The success of the REST-based "mega Web Services", such as Amazon, Google, and now Yahoo!, has some advocates of WS-Security scratching their heads. The predominant usage of these "mega Services" has not been"SOAP in, SOAP out", or even "XML in, XML out" (sometimes called POX - Plain Old XML). Instead, they are "HTTP Query String in, XML out". And, usually, an XSLT stylesheet is referenced, so it is actually "HTTP Query String in, HTML out".
These types of "REST-ian" Web Services are easy to use. Usually, the client is the Perl LWP module or Microsoft's XMLHttpRequest object. The client is not creating a SOAP message, or even an XML document. Because SOAP is not being used, anything else that relies on SOAP (such as WS-Security) cannot be used. Access control for these types of Web Services is usually implemented by issuing "developer tokens" to users. Therefore, there is "identification" but not authentication. i.e. the fact that a developer is sending up the token identifies the request as being sent on behalf of that developer, but there is no proof of their identity. Usually, each developer has a daily limit of requests which they can send to the Web Service. That's why you sometimes see developers post a REST-ian link to a Web Service up to their blogs, where the link contains their developer ID, and it works for a while but then stops working once the developer's daily limit has been reached. The Web Service does not know that all these requests were not the developer at all.
So what about security? Well, these Web Services are not receiving XML so any speculation about them being brought down by "malicious XML" doesn't hold much water. But, access control is an issue. As we have seen, the "developer token" approach provides identification not authentication. It is therefore a better idea to use HTTP authentication over SSL, with IP address identification also.
Confidentiality is also an issue. When details are passed in a HTTP GET query string, they can end up being stored in the logs of any number of proxies and caching servers between the requester and the Web Service, even if SSL is used. This is not an option for passing any data which is requires privacy.
The parameters passed to REST-Style Web Services are passed on the Query String. These can be validated to ensure that they are all present and correct, without any malicious content being present.
At Vordel we've realised for a long time that Web Services go beyond just "SOAP In, SOAP Out" or even "XML In, XML Out". Our products apply security to "REST-style" Web Services. In our Managment Console, you can configure policies for IP address identification, HTTP-Auth (and DigestAuth), and validation of HTTP Query Strings. In this way, you can apply security to a REST-style Web Service. This is "Web Services security" without WS-Security.
5:53:24 PM 
|
|
