Behold WSE 2.0: Removing Another Layer of WS-Pain

The official release of Microsoft's Web Services Enhancements (WSE) toolkit promises to help developers deal with at least some of the pain and suffering accompanying the emerging Web services' standards.Updated to support the OASIS WS-Security specification and a promising WS-Policy specification, developers will be able to build standards-compliant Web services in less time and with less code.

If you've been trying to keep up with the flurry of emerging, re-emerging, and otherwise evolving standards for Web services, your head is probably spinning. It is a difficult task to keep track of which standard is the favorite for standardization, which standards body has taken on what standard, and what toolkits have stepped up to support them. It would be great if we could just drag, drop, point and click our way to a successful enterprise Web services implementation without reading another boring XML specification. For this to become a reality, we need tools, good ones, and we need them all to play nice across platforms so we can "not care" about the underlying XML.

If you thought I was going to say that WSE 2.0 solves all of this, dream on. However, it does bring us one step closer to a mouse-driven paradise. Developers still have a responsibility to understand how emerging Web services standards such as WS-Security, WS-Trust, WS-SecureConversation, WS-Policy and so on (WS*) can be applied to their business workflows, but with WSE 2.0 they have a tool that helps them implement .NET Framework solutions productively.

In this article, I'll provide an overview of the key features that WSE 2.0 brings to the table, focusing on the applicability of WS-Security and WS-Policy standards as they sit today. I'll take you through building a Web service solution that requires a layered security model, writing as little code as possible, leveraging the WSE 2.0 VS.NET plug-in and its support for WS-SecurityPolicy to build the solution. I'll show you where I had to break down and write some code, wielding the extensibility of the WSE 2.0 pipeline to overcome some of the issues not yet addressed through the tool.

Applying Standards Gets Easier

The WSE 2.0 tool plugs in to the Visual Studio IDE just like WSE 1.0, through a set of tabbed dialog interfaces broken down by function. The new release continues to provide support for routing configuration, custom filters, and diagnostics. It also adds new support for publishing policy documents describing service requirements (see Figure 1) based on the WS-Policy specification, configuring support for signing and encrypting messages (see Figure 2) consistent with OASIS WS-Security, and configuring token issuance services based on WS-Trust and WS-SecureConversation standards.

Modifications made through these interfaces update the appropriate application configuration files (web.config or app.config) to enable features of the WSE run time, but this new tool also automatically generates policy cache files compliant with the WS-Policy specification. Developers can quickly generate policies to enforce the security requirements of a Web service, without writing a single line of code. This is indeed one of the most exciting new features of WSE 2.0).

The WSE 2.0 configuration tool does not replace a fundamental understanding of Web services standards, but it certainly helps. For example, I can point and click my way to a basic WS-SecurityPolicy that requires message signing and encryption; this generates compliant WS-Policy XML that can be shared with clients. Some functionality is not exposed through the tool interface, yet is supported by the Microsoft.Web.Services object model. For example, WS-Policy provides XML grammar for signing multiple parts of a message, and with some skillful hand-editing of the policy file, the run time happily supports this policy (see Signing Multiple Message Parts later in this article). In cases where specification elements are not supported by WSE 2.0, or its built-in run-time filters, you can create your own components to plug-in to the message processing pipeline.

WS-Policy Driven Architecture

The WS-Policy specification describes how Web services can publish requirements and validate messages against those requirements. This goes beyond Web Services Description Language (WSDL) that describes only wire-format. A policy might explicitly reject messages based on content or make certain message parts optional. WS-Policy provides a general XML grammar for describing policy assertions. Other specifications, such as WS-PolicyAssertions and WS-SecurityPolicy, provide specific applications of this grammar for their domains. WSE 2.0 provides rich support for WS-SecurityPolicy as will be demonstrated in this article.

WSE 2.0 automatically generates XML policy files that can contain WS-Policy descriptions for one or more Web service endpoints. This policy XML is used by the WSE run time to validate incoming messages (for example, to ensure that the message is properly signed), and to apply policies to outgoing messages (for example, to encrypt responses). XML policy is also used to publish policy information to calling clients. When WSE 2.0 is enabled for a client application, the run time can apply policy to outgoing messages, and validate messages returning from a Web service invocation.

This is all automatically handled by a set of pipeline filters included in the Microsoft.Web.Services.Policy namespace. PolicyVerificationInput and PolicyEnforcementOutput filters ingest policy XML to verify and enforce policy for incoming and outgoing messages, which means that we write less code. So, although the industry has yet to formally include WS-Policy within a standards organization, the application of WS-Policy at the tool level makes it possible for tools like WSE to automate policy-driven behavior.

WS-PolicyAttachments is a related WS-Policy specification for that describes how policies can be bound to WSDL or published through a UDDI interface. This part of the WS-Policy specification is not supported by tools today, so supplying Web service clients with a policy document is currently a manual process.

Support for OASIS WS-Security

WSE 1.0 supported a few core facets of the initial WS-Security specification; we were able to sign and encrypt messages with username token or digital signatures. Now that the WS-Security specification has stabilized and OASIS (Organization for the Advancement of Structured Information Standards) has it under its wing, we need an updated tool to support additional token formats, secure conversations, and to expose policy bindings as specified in the WS-SecurityPolicy specification.

One of the primary goals of the WS-Security specification is to provide an open specification that can support cross-platform security tokens and encryption standards. WSE 2.0 still supports username and X.509 tokens, but also adds support for Kerberos, security contexts compliant with WS-SecureConversation and WS-Trust, and extensibility to support XrML and SAML for single sign-on solutions.

I will show you how to apply several features of the specification for business scenarios that require a layered approach to Web services security. By the end of this article, you'll know how to apply WSE 2.0 to achieve the following results in a single solution:

• Identify application users for audit trail and authorization
• Control message privacy with encryption
• Verify message integrity by ensuring a trusted source
• Prevent message replay attacks

I'll also show you how much you can automate with WS-Policy support and where you have to write some code to fill in the missing pieces.

By: Michele Leroux Bustamante

Michèle Leroux Bustamante is a Principal Architect with IDesign Inc., a Microsoft Regional Director, and an internationally known speaker and author. At IDesign Michèle focuses on designing scalable and secure architecture, Web services tools and technologies, and best practices for hosting 24x7 operations and services. Michèle is a member of the INETA (International .NET Association) Speakers Bureau and is .NET MVP for XML Web services. With her experience in Java technologies, Michèle also serves as a BEA Technical Director, advises the Web services track of SD, and is Program Advisor to the Web services program at UCSD Extension. Reach her at www.idesign.net or www.dotnetdashbaord.net.