Browse DevX
Sign up for e-mail newsletters from DevX


Securing .NET Web Services with the WS-Security Protocol : Page 4

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.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Authenticating Security Tokens
When using Kerberos and X.509-based security tokens, WSE automatically attempts to authenticate the message sender using the appropriate mechanism. However, WSE will be able to authenticate Username tokens that represent Windows accounts only when the password is sent in clear text (PasswordOption.SendPlainText) by presenting the username and password to the system. First, unless you're using SSL, this is a very bad idea because the password is completely unprotected. Second, it requires ASP.NET to run with full system privileges. To securely use username tokens for authentication, you need to implement your own usernametoken manager, in a class that derives from UsernameTokenManager, and register it with WSE. This works particularly well for a custom authentication scheme; you simply retrieve the password that corresponds to the username and return it to WSE, which automatically compares it to the value of the password or password hash in the UsernameToken element. Even if you do not send a password, WSE can use your retrieved password to validate an attached digital signature, thereby verifying authentication. I don't have the space to fully cover security token managers here, but I do show how to do this in my book. You can also see this example on MSDN.

Adding Digital Signatures
As I mentioned, digital signatures become even more important in a custom username token-based scheme, since WSE can use them for authentication instead of a password or password hash. When you add a Signature object, which represents a digital signature, to the SoapContext for a message (see this code), WSE generates a digital signature over the message body—using the UsernameToken specified in the Signature object's constructor and adds it to a new Signature element in the Security header (see this code). At the other end, WSE uses the provided UsernameToken to verify the attached digital signature. To determine if a security token can be used to sign a message, check the token object's SupportDigitalSignature property. Encrypting Messages
You can use binary security tokens, such as X.509-based and Kerberos-based tokens, to encrypt part or all of a SOAP message. However, username security tokens do not support encryption. You can easily determine if a security token can be used for encryption by checking the token object's SupportsDataEncryption property.

To sum up, WS-Security provides a solid framework for securing SOAP messaging. However, other specifications like WS-Trust, WS-SecureConversation, WS-SecurityPolicy, and WS-Federation have been proposed to build even more robust and functional security scenarios. Out of the box, WSE provides an immediate security benefit by blocking all request messages that cannot be authenticated and that contain invalid digital signatures or encryption. With a little effort, you can configure WSE to provide much needed security for .NET Web services. While this article focused on username tokens, other solutions, like X.509, provide a higher level of security and functionality.

Jeannine Hall Gailey is a former Microsoft manager who has published numerous technical articles in diverse magazines and has written a book on the WSE and Web services specifications due out in February 2004 from Microsoft Press. You can reach Jeannine by e-mail here.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date