Does Microsofts support for the new WS-Security specification in Web Services Enhancements (WSE) 2.0 make you more inclined to deploy .NET Web services in your organization? Why or why not? Is the implementation easy to use? Do you think this and other proposed security standards will add sufficient security to Web services, or are they inherently so insecure that no amount of headers and encryption will be enough? Let us know in the .NET Technical discussion group on DevX.
Securing .NET Web Services with the WS-Security Protocol
The WS-Security specification lays the groundwork for securing enterprise Web services. The specification is complex, but using Visual Studio and Microsoft's WSE 2.0 Technical Preview you can easily apply the WS-Security protocol to your own Web services.
by Jeannine Hall Gailey
January 29, 2004
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.
It's quick, easy and you get access to all the articles on DevX.
This registration/login is to allow you to read articles on devx.com. Already a member?
To become a member of DevX.com create your Member Profile by completing the form below. Membership is free!
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.
