WSE 2.0 Settings

Developing Standards-compliant Web Services Is Now WS-Easy

ToolKit

LANGUAGES: C# | VB.NET

ASP.NET VERSIONS: 1.0 | 1.1

WSE 2.0 Settings

Developing Standards-compliant Web Services Is Now WS-Easy

 

By Ken McNamee

 

If you haven t heard, Web Services Enhancements (WSE) is a fully supported Microsoft add-on for the .NET Framework and Visual Studio.NET. Now in its second version, the goal of WSE is to simplify Web services development that makes use of all the new standards, such as WS-Security, WS-Policy, WS-Trust, and WS-ReliableMessaging, just to name a few. There are many more standards; most of them are used in combination to provide enhanced security, reliability, and platform interoperability to any Web services application. WSE is a broad subject; therefore, this article will focus only on the Visual Studio.NET tool that WSE installs to make it easy to configure a Web services application for any of these standards.

 

Enabling WSE

Once you ve downloaded and installed WSE 2.0, enabling its usage in your Web services application is as simple as selecting a checkbox. Inside Visual Studio.NET, right-click on the project name in the Solution Explorer and click the WSE Settings 2.0 item (at the bottom). You should now see the settings dialog box. As displayed in Figure 1, simply check the Enable this project for Web Services Enhancements checkbox and click OK. This adds an assembly reference to your project for the Microsoft.Web.Services2 namespace and also adds some configuration information to the web.config file.

 


Figure 1: The WSE 2.0 Settings dialog box provides wizards and an easy interface to reduce the complexity in configuring WSE for a Web services application.

 

Any existing Web services in your project will not automatically be WSE 2.0-enabled, however. You will need to regenerate them by clicking Update Web Reference. Once you do this there will be two proxy classes in your Web reference code-behind file. One will inherit from the standard System.Web.Services.Protocols.SoapHttpClientProtocol Web service base class. The other class, ending in Wse , will be WSE 2.0-enabled because it inherits from Microsoft.Web.Services2.WebServicesClientProtocol.

 

UsernameToken Security

One of the most common requirements for any application Web services-enabled or not is security. Doing security right is often frustrating and time-consuming. Using WSE 2.0, you can create a secure Web services application that is standards-compliant with a surprisingly small amount of code.

 

The simplest method for securing a Web service is through the use of a username and password requirement. Before WSE, you might have added username and password parameters to each of your Web method signatures and performed the authentication as the first line of code in the methods. If you got a little more advanced you might have used a custom SOAP header containing the credentials. This made your Web methods a little cleaner and allowed you to centralize the authentication because the SOAP header could be verified anywhere in the ASP.NET pipeline before it reached the Web method.

 

This is actually very similar to the way WSE works, using SOAP headers. Except with WSE, most of the plumbing code is already implemented, which allows you to focus only on your application-specific logic. In the case of securing a Web service with a username and password, WSE accomplishes this via a UsernameToken class, which is serializable and encapsulates the credentials. The UsernameToken class is added by the client to the Tokens collection of the Web service proxy class. When the SOAP request gets sent to the server, UsernameToken is automatically converted to a custom SOAP header. This header is then deserialized back into a UsernameToken class by the server. The username and password contained within the token can then be authenticated by overriding the Authenticate method of a UsernameTokenManager class.

 

Policy Files

Before WSE, you usually had to write code in each Web method to ensure that the proper credentials were passed in. With WSE 2.0 and a custom token, you can use a configuration file to specify what type of security to use and which parts of the SOAP message to secure. These configuration files are called policy files and the WSE 2.0 Settings dialog box makes it very simple to set this up. On the Security tab, simply add a new Security Token Manager for your UsernameToken. Then on the Policy tab, check Enable Policy and add a new application policy. In Figure 2 you can see a slimmed down policy file that enforces the UsernameToken requirement on all SOAP requests.

 

 

 

   

     

   

 

 

 

 

   

     wsp:Body()

   

   

     

       

         

           

             

               

                 http://docs.oasis-open.org/...

                   wss-username-token-profile-1.0

              

             

           

         

       

     

    wsp:Body()

  

 

 

Figure 2: The WS-Policy configuration file can enforce that a Web service can only be called and authenticated under certain circumstances without the need to write any code.

 

Conclusion

WSE 2.0 does much more than enable easier Web services security. There are classes for encrypting all or part of SOAP requests and responses without the need for SSL. There are classes for ensuring the reliable delivery of messages and classes for routing these messages through a complex enterprise network architecture. These are capabilities that were extremely difficult, if not impossible to accomplish in the past by rolling it yourself. In my opinion, a best practice recommendation is that any new Web services development going forward should use as much of WSE 2.0 as possible.

 

Resources

 

Ken McNamee is a Senior Software Developer with Vertigo Software, Inc., a leading provider of software development and consulting services on the Microsoft platform. Prior to this, he led a team of developers in re-architecting the Home Shopping Network s e-commerce site, http://www.HSN.com, to 100% ASP.NET with C#. Readers can contact him at [email protected].

 

 

 

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish