Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


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

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.




Application Security Testing: An Integral Part of DevOps

Adding a Security Token
Because all messages sent to a WSE-enabled application must contain at least one security token, you need to instruct WSE to add a username token to the application's request to the Hello World Web service. You do that by adding a UsernameToken object to the SoapContext for the request message. The following code adds a UsernameToken and a new digital signature to the SoapContext object before making the Web service request to the GetHelloWorld method.

// Instantiate the HelloWorldWse class. HelloWorldWse myService = new HelloWorldWse(); // Get the SoapContext object for the // outgoing message. SoapContext myContext = myService.RequestSoapContext; // Instantiate a new UsernameToken object. UsernameToken myToken = new UsernameToken(myName, myPwd, PasswordOption.SendNone); // Add the token to the SoapContext. myContext.Security.Tokens.Add(myToken); // Generate a signature using the username token, // and add the signature to the SoapContext. myContext.Security.Elements.Add( new Signature(myToken)); // String for the "Hello World" response. string response = ""; try { // Call the Web method. response = myService.GetHelloWorld(); } catch(Exception ex) { // Do error handling here. }

Note that by using a signature as proof-of-possession, you can specify the PasswordOption.SendNone so WSE doesn't send the password in the header.

In this case, WSE generates a UsernameToken element in the message's Security header. The following code shows the WS-Security header from a digitally signed message. When WSE digitally signs a message, it uses the supplied security token to generate the signature. WSE generated this Security header using the UsernameToken object shown in the preceding listing.

Author's Note: I removed some of the URI strings and repeating Reference elements from the code below to improve readability.

<wsse:Security soap:mustUnderstand="1"> <wsu:Timestamp wsu:Id="&#133;" xmlns:wsu=""> <wsu:Created wsu:Id="&#133;" >2003-12-11T06:57:26Z</wsu:Created> <wsu:Expires wsu:Id="&#133;" >2003-12-11T07:02:26Z</wsu:Expires> </wsu:Timestamp> <wsse:UsernameToken xmlns:wsu="&#133;" wsu:Id=""> <wsse:Username>author@webbish6.com</wsse:Username> <wsse:Nonce>LVovrPhjLV4bcXnhoyEE6g==</wsse:Nonce> <wsu:Created>2003-12-11T06:57:24Z</wsu:Created> </wsse:UsernameToken> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> <CanonicalizationMethod Algorithm="&#133;" /> <SignatureMethod Algorithm="&#133;" /> <Reference URI="&#133;"> <Transforms> <Transform Algorithm="&#133;" /> </Transforms> <DigestMethod Algorithm="&#133;" /> <DigestValue>&#133;</DigestValue> </Reference> &#133; </SignedInfo> <SignatureValue>&#133;</SignatureValue> <KeyInfo> <wsse:SecurityTokenReference> <wsse:Reference URI="&#133;" ValueType="wsse:UsernameToken" /> </wsse:SecurityTokenReference> </KeyInfo> </Signature> </wsse:Security>

When instantiating a UsernameToken object, you have the option of specifying how WSE handles the password, which you must always supply. Never hard-code passwords into your application. When WSE adds a UsernameToken element to the message, it creates a Username element as well as Nonce and Created elements. These elements hold data used to prevent replay attacks and to stiffen a hashed password against dictionary attacks when using the PasswordOption.SendHashed option. However, because even a hashed password is vulnerable to a brute force dictionary attack, a better solution, aside from encrypting the transport, is to use the PasswordOption.SendNone option.

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