email article printer friendly more resources

Secure Your Web Services
Know your options for implementing Web services safely—now and in the future.
by Geir Olsen

March 2003 Issue

For this solution: Web services, SSL/TLS, XML, SOAP, WS-Security, WS-Policy, WS-Trust, WS-Authorization, WS-Privacy, WS-Secure Conversation, WS-Federation, XML Digital Signatures, XML Encryption

Rarely has a new computer technology been embraced and promoted (and, to some degree, adopted) at the speed Web services technology has—proof that there's demand in the marketplace for the functionality it offers. If you're developing Web services with security features, though, you're either a pioneer or you've moved in before the construction crew has moved out. Web services security is still a work in progress. I'll help you understand where it stands today, what technologies you should use to start building secure Web services now, what you can expect in the near and more distant future, and what steps you can take to ensure you make as smooth a transition as possible between current and future technology.

If you're looking at using Web services today, plan on a simple deployment model that employs Secure Sockets Layer/Transport Layer Security (SSL/TLS) or Windows Integrated Security. Microsoft did release a technology preview of its Web Services Development Kit (WSDK) in August 2002, and might be out with an update by the time this article is in print. However, the technologies the kit includes will probably see numerous changes over the next year, as the various Web services standards gel (see the sidebar, "Know Your Web Services Specifications"). I recommend you stick with SSL/TLS for your production environments until final releases of the new technologies are out.

Take a look at a simple model that uses SSL/TLS (see Figure 1). TLS replaces SSL (its last release was version 3.0) and many people refer to it as SSL 3.1. According to Microsoft, TLS and SSL are incompatible, and it recommends you adopt TLS for new projects. (I'll use the SSL/TLS acronyms together, because more people are familiar with the technology under the name SSL.) In this model, the client sends Web services message requests to the Web services provider over a secure SSL/TLS channel that's established through a handshake at the interaction's outset. Each subsequent message is encrypted and digitally signed to ensure the message's confidentiality and integrity. Single- or dual-sided authentication takes place during the initial handshake. The Web server hosting the Web services provider always has a certificate that enables a client to authenticate it; SSL/TLS also enables you to configure client certificates so that the Web services can authenticate the calling clients securely.

Figure 1 Request Messages Over a Secure Channel

SSL/TLS is in widespread use today, and all major Web servers, including Internet Information Services (IIS), support it. A Web server and your browser use the same infrastructure when you check out an order from Amazon.com. To incorporate SSL/TLS into your own solutions, start by obtaining a certificate from VeriSign or one of the other certificate authorities (CAs) on the Internet, then bind the certificate to a Web site or a whole Web server. You have the option to configure client certificates to enable bulletproof client authentication. In the initial handshake between client and server, cryptography technology ensures the server is who it says it is and—if client authentication is configured—that the client is allowed to talk to the server. A SSL/TLS solution is highly secure, but it doesn't scale well because it's extremely resource-intensive.