Securing .NET Web Services with the WS-Security Protocol

or years now, SSL has been the magic bullet for securing HTTP messaging. While you can use this encryption-based technology to secure SOAP messages over HTTP, it limits Web service functionality. SSL requires a negotiation between messaging endpoints to exchange keys and establish encryption, so messaging secured by SSL must be fully decrypted at each endpoint before the contents of a message can be read. In other words, when using SSL, your application must pay the processing cost of decrypting each message—even before it can read the SOAP message headers to determine, for example, that the message needs to be re-encrypted and forwarded to another application. Clearly, applications need a security solution that better enables such complex message routing. To fulfill that need, representatives from IBM, VeriSign, and Microsoft teamed up to draft the WS-Security specification.

Inside the WS-Security Specification
WS-Security introduces the concept of security tokens. These XML-based tokens contain claims about the sender of a SOAP message, and can include data sufficient to prove these claims. Username tokens, which will be the focus of this article, can contain a username and optionally a password or a cryptographically-derived password hash. Signed security tokens, such as X.509 or Kerberos-based tokens, are binary security tokens encoded as base-64 binary XML. They include cryptographic endorsements made by a token-issuing authority.

SOAP messages transport these security tokens in the new Security header element. Applications can use the header contents to authenticate the sender and secure the message itself. Rather than proposing a new set of security technologies, WS-Security leverages existing XML security specifications, including XML Encryption and XML Signature; cryptographic algorithms, such as SHA-1 and Triple-DES; and authentication mechanisms, such as X.509 and Kerberos.

When using SSL, your application must pay the processing cost of decrypting each message.

Implementing WS-Security
To implement the WS-Security specification in your Web service or consuming client application, you must be able to write security elements to and read them from your SOAP messages, and you must have access to standard cryptographic algorithms. While it's certainly possible to do the necessary XML serialization yourself, you can avoid extra work by leveraging out-of-the-box implementations of WS-Security offered by IBM, Microsoft and others. In this article, I will focus on Microsoft's implementation of WS-Security in its Web services Enhancements (WSE) offering. In particular, you'll see how to use the WSE 2.0 Technical Preview release to secure a request to the classic "Hello World" Web service.