Enterprise Software

New tools make Web services more secure and practical

While the jury debating Web services is still out for most enterprises, there are some new compelling reasons to deliberate. Tim Landgrave describes how Microsoft's Web Services Software Development Kit opens up intranet/extranet implementations.


Though it was initially hailed as the Holy Grail of interoperable computing, most companies have pursued only limited adoption of Web services. On the Internet, Web services have been relegated to primarily read-only public services such as ZIP code lookups and Web search engine interfaces. Companies using Web services for intranet or extranet development have found compelling enterprise application integration uses for the technology but only in circumstances in which both systems had well-defined interfaces and secure links.

That’s because without extending the standards, the existing Web services protocols had no provision for security outside whatever was provided by the platform. Without the ability to reliably route the SOAP messages generated by Web services either around down servers or through the most efficient path, Web services clients couldn’t guarantee that messages could be reliably sent and received between them and the servers hosting Web services.

IBM, Microsoft, and other members of the Web Services Interoperability group (WS-I) have been working for months to agree on security and routing principles to define how development products would implement new extensions to support Web services security and routing. These principles made a big step from the theoretical into reality recently with Microsoft’s first release of its Web Services Software Development Kit (WS-SDK).

The standards effort
Perhaps the most important thing to point out about the WS-SDK is that it is Microsoft’s implementation of the WS-Security specification published on 11 April 2002. This joint IBM, Microsoft, and VeriSign publication of the specification was also submitted to OASIS on June 27. (The public specification was updated on August 20 by IBM, Microsoft, and VeriSign.) In the coming weeks, IBM, BEA, Oracle, and other key WS-I members, who market development tools, will release either toolkits or beta versions that support the now-published specification. Within the next six months, I expect these vendors to release final versions of toolkits that will allow organizations to use the products to create secure, routable Web-services-based applications that work cross-platform without any additional coding or configuration.

The best way to understand how these standards will provide that flexibility is by examining the core elements of the WS-SDK.

The WS-Security standard
Security is the most important issue that companies need to resolve before Web services become usable on public networks. WS-Security describes enhancements to SOAP messaging that provide a means to guarantee message integrity and confidentiality. The standard wasn’t designed around a specific security model or encryption technology but was designed to accommodate existing and future technologies in a generic way.

WS-Security also provides a general-purpose mechanism for associating security tokens with messages, which could be useful in a scenario in which, for example, an ISO-9000 certified manufacturer only wants to buy parts from another ISO-9000-certified supplier. In this scenario, rather than requiring the manufacturer to maintain certification information manually, the supplier could electronically request an ISO-9000 certification token from the standards organization and then submit that token along with proof of identity and its message containing bid information for parts it wishes to supply. The proof of identity can be contained in existing X.509 certificates or Kerberos tickets. WS-Security describes how to encode these binary security tokens.

Although Microsoft, IBM, and other key players have agreed to follow WS-I standards, there are still holdouts—most notably Sun, which is pressing the W3C to aid in the standards process and is also championing other standards like the Security Assertion Markup Language (SAML) and the eXtensible rights Markup Language (XrML).

The WS-I anticipated the need for interoperability with non-WS-I participants, so it has also released the Web Services Security Profile for XML-based Tokens. This document describes how to use XML-based tokens such as SAML or XrML with the WS-Security specification.

How the WS-SDK implements WS-Security
Let’s look at the method that Microsoft used to implement the WS-I standards with its WS-SDK. The WS-SDK implements the WS-Security standards by providing an engine for applying advanced Web service protocols to SOAP messages. This engine consists of two sets of filters that process inbound and outbound messages. These filters write headers to outbound SOAP messages and read headers from inbound SOAP messages. When required, the filters can also process the SOAP message body.

For example, the outbound filter can encrypt an outbound message and the inbound filter can decrypt the body of an inbound message using the standards defined by the WS-Security specification. The outbound message filter processes all outbound messages, for example, request messages from a client to the server or response messages from server to the client. Likewise, the inbound message filter processes all inbound messages, for example, request messages to a server from a client or response messages to a client from a server.

Microsoft’s implementation of the WS-SDK highlights the extensibility features of the .NET Framework upon which it’s built its future Web services foundation. Rather than requiring an update to the existing .NET Framework, Microsoft implemented the inbound and outbound filters using native .NET functionality. The new class definitions required by WS-Security are implemented as subclasses of existing .NET objects.

The filters are implemented on the server using ASP.NET HTTP modules, an extensibility mechanism that allows any .NET application to specify the chain of events that should occur when messages are sent or received through an ASP application. Web services applications that use the WS-Security extensions provided by the WS-SDK can run side by side with applications using native .NET support for Web services, making migration clean and simple. The WS-SDK uses similar techniques to implement the WS-Routing and WS-Attachment standards.

A significant step
The release of the WS-SDK and future vendor toolkits mark a significant change in the way developers will approach Web services. Until now, anyone who wanted to implement highly secure and routable Web services had to use their own proprietary extensions, manually modify (or hand-code) the Web Services Description Language (WSDL) generated by their toolkits, and customize the SOAP messages at a very low level.

With the release of these specifications and the toolkits that support them, the development platform now handles the details of generating the proper WSDL and SOAP messages. Cross-platform security and routing becomes automatic if you’re using a vendor’s toolkit that implements the WS-I standards. Later this fall, when the WS-I releases its Transaction and WS-Coordination standards, the last two dominoes will fall in the quest for truly platform-independent, interoperable processes.

Editor's Picks