Web services security: A status report

If the blizzard of specifications related to Web services security has left you snow blind, you have plenty of company.

WS-Security, from Microsoft, IBM, and VeriSign, deals with the protection and confidentiality of SOAP messages using a variety of techniques. It’s hard to keep WS-Security firmly in view because the prefix “WS” is connected to a laundry list of words and phrases, including “Attachments,” “Authorization,” “Coordination,” “Federation,” “Inspection,” “Policy,” “Privacy,” “Referral,” “Routing,” “Secure Conversation,” “Security,” “Transaction,” and “Trust.” Is “WS-World Peace” far behind?

Also, there’s SAML (Security Assertion Markup Language), the OASIS spec that defines the formats and protocols according to the assertions — which report that someone was authenticated by some authority or granted or denied access to some resource — that can be represented and processed. The Liberty specifications, which build on SAML, may or may not use WS-Security and define how single sign-on (driven by federated identity) can work for decentralized populations of users, identity providers, and services.

Each of these specs tackles a different kind of problem. None offers what some people seem to expect: an alternative to SSL/TLS (Transport Layer Security) encryption wrapped around password-or ID-based authentication. Nor is such an alternative likely to emerge.

There aren’t any new basic techniques and, if there were, they’d apply equally to all aspects of security, not just to Web services. What’s now being elaborated, slowly and painfully, are “use cases”: scenarios for authenticating users, authorizing access to Web services, and federating identity across sets of Web services.

XML is woven through all these specifications, but as in the case of the various XML standards managed by the W3C, proliferation is making it tough to decide which core XML security standards will finally matter. What’s more, the XML lingo used in most of these specs is humanreadable only for a limited definition of “human.” Really, this XML is object code that tells machines how to enact scenarios. Words and pictures present these scenarios in ways that people can more easily consider, discuss, and agree to. Kudos to the Liberty Alliance for applying that principle in its architecture overview at

As we’ve said elsewhere, the techniques repurposed by the various Web services specs — certificate and key management, signing, and encryption — are famously difficult for people to understand and apply (see ” Liberty trumps Passport agenda “). Another problem looms as the need to secure Web services puts more people in charge of controlling access to more resources. “We think human scalability is the real bottleneck,” says Greg Wilson, a principal software developer at Baltimore Technologies in Needham, Mass.

XML may be a good way to represent ACLs (access control lists) to machines, but how can people be empowered to understand and manage complex and overlapping sets of security assertions and policies?

Here is the bottom line: The requirements of Web services security present no new problems, but will force the IT community to repackage known solutions in more usable ways.

— Jon Udell

Source: www.infoworld.com