I've added two links on my blogroll to two respected commentators on Web Services Security: Gunnar Peterson and Pete Lacey. Gunnar and Pete had a useful exchange of blog posts on the subject of REST security and SOAP message-level security, back in December.
Here is my perspective, as a vendor, on the SOAP and REST security debate:
Firstly, I think that unfortunately the word "security" is a problem here. For REST and SOAP Web Services, "security" can usually be dissected into at least three parts: (1) Encryption of data on the wire, (2) controlling who can access the Web Service, and (3) protection against attacks against Web Service which exploit platform loopholes and insecure code. If you ask "is that Web Service secure", one person may say "yes, because all the data sent to it is encrypted", another may say "yes, because only authenticated clients can access it", while another may say "yes, because we validate all the data which is passed into it and we've reviewed the code for vulnerabilities". All of these answers are correct at some level, but are only part of what makes a Web Service "secure". In fact, one answer which is not valid is "the Web Service is secure because we use WS-Security". Although it would seem logical that WS-Security is Web Services Security, it is not. Let's look into this further:
SSL
It's usually assumed that vendors like Vordel who are associated with "Web Services Security" will argue that WS-Security should always be used instead of SSL. In fact, "Web Services Security" is often assumed to be an alternative to SSL. However, this is not the case. Most of our customers use SSL. One of the things our appliances do is to accelerate SSL. Our products make it easy to configure SSL, by allow our users to right-click on Web Service endpoints and configure SSL interfaces. Our SOA policy managment tool also generates SSL certificates.
So where is SSL lacking? Here are two ways which we see at a practical level, in our architectural planning sessions with customers:
1. Management and governance. One of the big issues with SSL for Web Services is configuring managing the SSL configurations which are in place across a network of Web Services on different platforms. Often, the certificates have been installed on the Web Services platforms, but no central management and governance of the whole system. We provide the visual tools to look at each Web Service endpoint across an SOA and see what policies are in force there. Right-click on the endpoints in Vordel's Management Console and you see the SSL certificates in place there, and whether clients need to authenticate with their own certificates also.
2. SSL creates a tunnel through firewalls right to the Web Service endpoint. This sounds like a good thing, right? Unfortunately, it's not. That "secure pipe" could contain anything at all, and it's invisible to regular network firewalls. For cross-firewall Web Services, it's a better idea to install an XML Gateway to terminate the SSL connection at the perimeter, inspect the request, perform routing, logging, and then forward the request to the service. Since XML Gateways are optimized for this functionality, they take load of the Web Services platform themselves. The XML Gateway also has a number of other useful emergent benefits; for example, it sees the response times of the Web Services and sends alerts if a Web Service is not performing up to the expected level. They also are used to shape traffic so that Web Services are not overwhelmed by client requests, and to enforce usage levels so that clients can only access Web Services according to the usage level which they have paid for.
When is WS-Security used?
So where is WS-Security being used then? Pete Lacey's blog mention that "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". Jon Udell ran a similar survey when he was at Infoworld, and interviewed a Vordel customer who uses WS-Security. Jon pointed out that the WS-* standards were often being used for security interoperablity reasons, between security products, rather than being used as part of Web Services transactions.
We certainly see both of these uses of WS-Security: passing identity tokens and security interoperability. When an XML Gateway is deployed to perform SSL authentication or HTTP basic/digest authentication in the DMZ, it is important to pass information about the authenticated client (the "principal") to the Web Service itself. WS-Security is ideal for this, since it allows identity tokens to be embedded into the XML messages sent to the Web Services. This type of "principal propagation" architecture is shown below:
Vulnerabilities
It goes without saying that XML Gateways are usually used to filter XML traffic. The problem with protecting REST Web Services is that the input into REST Web Services are almost always HTTP GETs (notwithstanding the fact that one of the cornerstones of REST is to use all of the HTTP "verbs", not only GET). Filtering this traffic means examining the parameters passed in URL QueryStrings, ensuring it is appropriate for the service being addressed. So, it is not "SOAP in, SOAP out", or even "XML in, XML out", but instead it is "HTTP GET in, XML out". Vordel's products filter this type of traffic by scanning the HTTP QueryString parameters for threats, and applying regular expressions to make sure that the content is appropriate [similar to how Web Application Security products operate].
Best of both worlds
Finally, there is an option for organizations which want to expose the same services as both REST and SOAP Web Services: Use an XML Gateway to do the "protocol mediation" between the two styles. This allows you to give both options to clients, in a secure manner, without changing the Web Services themselves (or opening them up to the direct "line of fire" from clients). In other words, forget the REST vs SOAP argument, and instead use an XML Gateway to mediate between them.
Link to my presentation on Security for REST Web Services at RSA 2006: http://radio.weblogs.com/0111797/2006/02/20.html
9:03:14 PM 
|
|
