Desperately seeking clarity
Web services security is getting a lot of air time these days. On the down side, the naysayers are attempting to put a stop to prospective implementations with Nostradamus-like predictions and warnings (reminding me of the guy I used to see at 17th and Market in downtown Philly). On the up side, we have companies like Microsoft and IBM issuing Web services security "teddy bears" in an attempt to make the whole world feel better (and I thought drinking Coca-Cola was all we needed). Let's cut through the hype of Web services security to the meat of the issues.
THE HURWITZ TAKE: Repeat after me "Securing Web services is no different than securing every other technology on the planet." The concepts are always the same - ensuring integrity, authenticity, confidentiality, and availability of the components and the transactions. Like energy, we have data at rest (potential) and data in motion (kinetic). Protect them both, at every point and between the points. Sound hard? Well, we have 30-years of hard-earned security knowledge that doesn't just disappear. Put it to work.
The scary thing to some is that these are new applications. Hmmm, with this line of reasoning, you can stop everything you are doing now. I wonder, if we knew five-years ago how absolutely rife with security vulnerabilities Web servers would be, should we have stopped Amazon.com and eBay and Yahoo and E*Trade from existing? The real question is always is it worth the risk? And the answer with Web services is yes, absolutely. By the way, if you answer no, that's okay, but STAY OUT OF THE WAY.
Let's move on to some quick debunking: for some reason, analysts and press have taken to saying that Web services implementations should be "inside the firewall." This is perhaps the biggest red herring since people proclaimed (and some still mistakenly believe) that SSL is useful in securing a Web site. I return again to potential data (Web site, insecure) and kinetic data (communications, secure for a short period, then insecure). Aren't all application servers behind a firewall of some sort?
Let's be clear -- the (network) firewall does as much to protect Web services as it does to protect any other service. It can block traffic entirely, or let it through. Web services uses port 80 (http) -- what do you think the firewall will do to that traffic? That is perhaps the easiest decision the firewall administrator has to make in his life -- the first port you open is port 80. So the firewall really adds no more protection than it does for today's Web servers, which isn't a whole lot. This should have been clear since the early days of Web services when vendors were proclaiming that it was "firewall-friendly."
The real point to be made with Web services security is that you should have control over all of the components, particularly in the early stages. That is, a source and destination host, perhaps using an intermediary UDDI or WSDL service, should be under your direct or contractual control. These components should be hardened at all layers to protect the stored data, and application control solutions (like those from Okena and Harris) should be in place to protect against exploits against the inevitable bugs that will come during the WWWF's (worldwide web federation) Patchmania II.
When it comes to protecting the transaction, two standards stand out -- XML Encryption (confidentiality) and XML Signature (integrity and authenticity). Data, in all its forms, can be encrypted and signed. These standards provide ways to characterize the results of these operations within an XML document. As with any transaction, you also want audit capability. The solution from Forum Systems already implements these features. OASIS' XACML should provide an interesting development when it matures, providing the ability to standardize on access control policy statements.
Other security standards are being developed that leverage Web services to extend security in the existing environment. That is, they basically use Web Services for what it is intended, to provide data in context at a layer of abstraction that allows for interoperability. SAML leads the way here, giving web access control vendors the ability to present user authentication and authorization information to other domains. Current implementations come from Entegrity, Sigaba, Baltimore, Vordel, and Quadrasis, with others on the way. XKMS also fits here with its ability to present certificates and check their validity. Vordel and Verisign fit in here.
Vendors have learned that firewall-friendly isn't necessarily a good thing, and recently Microsoft and IBM have come out with their proposed security roadmap, which provides warm fuzzies until you read the copyright notice with its phrases like "preliminary document" and "may be changed substantially" and "not be interpreted as a commitment" and "cannot guarantee the accuracy." And, since this notice consumes the entire first page, it almost doesn't seem worthwhile to read the rest of the document.
Let me see if I can do a better job singing this lullaby: There are plenty of standards and solutions in existence today and coming out in the near future that provide the necessary security for many Web Services deployments. That doesn't mean security is guaranteed -- it never is -- it just means that we will survive.
Copyright 2002 Hurwitz Group Inc. This article is excerpted from TrendWatch, a weekly publication of Hurwitz Group Inc. - an analyst, research, and consulting firm. To register for a free email subscription, click here.
For More Information:
- Looking for shortcuts and helpful developer tips? Visit our Tip Exchange for time-saving XML and .NET tips.
- Visit our huge Best Web Links for Web Services for hand-picked resources by our editors.
- Discuss this article, voice your opinion or talk with your peers in our Discussion Forums.
- Visit Ask the Experts for Web services, SOAP, WSDL, XML, .NET, Java and EAI answers.