WSE 2.0 Settings

ToolKit

LANGUAGES:C# | VB.NET

ASP.NETVERSIONS: 1.0 | 1.1

WSE 2.0 Settings

Developing Standards-compliant Web Services Is NowWS-Easy

By Ken McNamee

If you haven t heard, Web Services Enhancements (WSE) is afully 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 servicesdevelopment 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 aremany more standards; most of them are used in combination to provide enhancedsecurity, reliability, and platform interoperability to any Web servicesapplication. WSE is a broad subject; therefore, this article will focus only onthe Visual Studio.NET tool that WSE installs to make it easy to configure a Webservices application for any of these standards.

Enabling WSE

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

Figure 1: The WSE 2.0 Settings dialogbox provides wizards and an easy interface to reduce the complexity inconfiguring WSE for a Web services application.

Any existing Web services in your project will notautomatically be WSE 2.0-enabled, however. You will need to regenerate them byclicking Update Web Reference. Once you do this there will be two proxy classesin your Web reference code-behind file. One will inherit from the standardSystem.Web.Services.Protocols.SoapHttpClientProtocol Web service base class.The other class, ending in Wse , will be WSE 2.0-enabled because it inheritsfrom 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 oftenfrustrating and time-consuming. Using WSE 2.0, you can create a secure Web servicesapplication that is standards-compliant with a surprisingly small amount ofcode.

The simplest method for securing a Web service is throughthe use of a username and password requirement. Before WSE, you might haveadded username and password parameters to each of your Web method signaturesand performed the authentication as the first line of code in the methods. Ifyou got a little more advanced you might have used a custom SOAP headercontaining the credentials. This made your Web methods a little cleaner andallowed you to centralize the authentication because the SOAP header could beverified anywhere in the ASP.NET pipeline before it reached the Web method.

This is actually very similar to the way WSE works, usingSOAP 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 caseof securing a Web service with a username and password, WSE accomplishes thisvia a UsernameToken class, which is serializable and encapsulates thecredentials. The UsernameToken class is added by the client to the Tokenscollection of the Web service proxy class. When the SOAP request gets sent tothe 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 authenticatedby overriding the Authenticate method of a UsernameTokenManager class.

Policy Files

Before WSE, you usually had to write code in each Webmethod to ensure that the proper credentials were passed in. With WSE 2.0 and acustom token, you can use a configuration file to specify what type of securityto use and which parts of the SOAP message to secure. These configuration filesare called policy files and the WSE 2.0 Settings dialog box makes it verysimple to set this up. On the Security tab, simply add a new Security TokenManager for your UsernameToken. Then on the Policy tab, check Enable Policy andadd a new application policy. In Figure 2 you can see a slimmed down policyfile 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: TheWS-Policy configuration file can enforce that a Web service can only be calledand authenticated under certain circumstances without the need to write anycode.

Conclusion

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

Resources

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