Columns

Web services security? Not yet.

• By David Chappell
• March 28, 2003

Security is the biggest unsolved problem in Web services today. Without an effective way to authenticate clients, guarantee the integrity of transferred data and to ensure data remains confidential during transit, Web services can be applied only in limited ways. The lack of good SOAP-based security mechanisms has had two main impacts. One is that firms tend to use Web services in situations where less-secure communication is acceptable, such as integrating apps inside the firewall. The other is that various less-than-ideal workarounds have been found to make communication with SOAP more secure. SSL can be used for point-to-point connections, for example, as can IPsec or the various security techniques employed by VPNs. Still, the real solution is to define a way to provide intrinsic, end-to-end security for SOAP messages.

WS-Security, a specification created mostly by IBM and Microsoft, is intended to address this problem. Rather than define a wholly new set of security mechanisms, WS-Security defines how to use existing mechanisms to provide authentication, integrity and confidentiality for SOAP messages. This makes perfect sense; there are plenty of security mechanisms in existence, so there's no need to invent new ones. WS-Security defines how to use username/ password pairs, Kerberos and public key technology to provide security services for SOAP messages. It also allows the use of other approaches.

Because it tells implementers exactly how to use today's most common security mechanisms, WS-Security solves a critically important problem. Unfortunately, it doesn't solve the complete problem of providing Web services security. The reason for this is that while the WS-Security spec defines how to use different security technologies with SOAP, it doesn't make support for any particular technology mandatory. It's entirely legal for one implementation to support only Kerberos, for example, while another supports only public key-based security.

It's hard to imagine how the people who defined WS-Security could have done a better job in solving this problem. The truth is that there is no single security mechanism that's appropriate in all situations. For example, Windows 2000 domains use Kerberos, which suggests that clients accessing Web services within this limited world will also use Kerberos. Microsoft tells us that Passport, its Internet-based authentication service, will eventually support Kerberos, so one could imagine that companies might one day be able to use Kerberos to securely access Web services on the Internet. Today, however, it's much more common to use some kind of public key-based security on the Internet and even internally.

I wouldn't be surprised to see the Web Services Interoperability Organization (WS-I) define a profile for using WS-Security. Chances are, though, that the group will define profiles for both Kerberos and public key-based approaches rather than mandate one or the other. Given the state of the security world today, how could they force just one choice?

In the end, clients needing to access Web services that require different security mechanisms will probably need to support multiple mechanisms themselves. This is certainly possible; a spec called WS-Security Policy defines a way for a Web service to clearly define its security requirements, allowing clients to understand exactly what's required. Similarly, another related spec, WS-Trust, defines how to use SOAP to request appropriate security tokens such as a Kerberos ticket.

Still, it would be nice if WS-Security and the associated specs were the only things needed to let everybody use SOAP in a secure, interoperable way. Given the realities of the world, however, they aren't. While these specifications are an important step toward secure Web services, they're not a panacea. As usual, perfect solutions to hard problems aren't easy to come by.