Columns

.NET and Beyond: The big bet

• By David Chappell
• September 29, 2003

I can’t help admiring the ambition of people working on Web services security. The problem they face -- creating multivendor agreements on authentication, authorization and more for SOAP -- is tremendously difficult. Not only that, but in a very real sense, no one has ever solved this problem before. Complete multi-vendor security for distributed applications? Please -- it’s been a pipe dream. Yet the existing Web services work in this area is actually nearing completion.

To make clear what I mean, I’ll summarize the various standards for Web security today. The foundation is WS-Security, which defines add-ons to SOAP that can be used to authenticate messages, guarantee their integrity, and ensure their confidentiality. For integrity and confidentiality, the specification mandates the use of the existing W3C standards in these areas: XML Signature for integrity, and XML Encryption for confidentiality.

Authentication is a more difficult problem. Various schemes are in use today to prove identity, and so it would be tough for the creators of WS-Security to mandate any one of them. Given this, the spec instead defines the notion of a security token, then specifies how certain security tokens, including Kerberos tickets, X.509 certificates and user name/password pairs, should look. If I’m using the same authentication mechanism (and hence the same kind of security token) as the Web service I wish to invoke, life is great.

But what if I’m not? In this probably quite common case, I can rely on the technology defined in another spec called WS-Federation. Among other things, this document describes how I can use one security token, such as a digital signature and X.509 certificate, to request another one, such as a Kerberos ticket. Even though these tokens were issued in different security domains, I can still securely invoke my desired Web service as long as trust can be established between those domains. In other words, all is well as long as these domains have been federated into an interoperable security environment.

Next problem: How do I know what kind of authentication mechanism my target Web service uses? The answer is provided, of course, by another spec. This spec, called WS-SecurityPolicy, defines a way for the creator of a Web service to express its requirements and preferences for security. A service’s policy might require its client to use Kerberos, for example, or it might indicate that it prefers Kerberos but can also support authentication using X.509 certificates.

One last problem remains. How do I acquire the security policy information for the Web service I want to invoke? The answer appears to be by using another soon-to-be-published pro-tocol that allows me to access various information about a service, including its security policies.

Everything clear?

Once again, let me express my admiration for the ambition of the people creating this technology. And I’m not criticizing their work -- I like this group of technologies. But we need to be aware of what’s happening here. How long will it take for all of these wonderfully crafted documents to come together into a coherent, interoperable and secure set of software supported by every vendor?

Going forward, Web services is how we will communicate between applications, while WS-Security and its fellow travelers are how we will secure that communication. But succeeding with Web services depends on winning the big bet we’re placing on this multi-part security scheme. If all goes well, we’re looking at a huge payoff. But everybody working in this area, both vendors and users of Web services, needs to pay serious attention to these emerging technologies. Understanding their importance is one of the best ways to tilt the odds in our favor.