n October 2003, Microsoft announced the technical preview of its Web Services Enhancements for .NET
(WSE) 2.0 toolkit. This release implements some of the new Web Services Architecture (WSA) specifications that Microsoft, IBM, and BEA have been working on together, and it improves existing specifications such as WS-Security. This article examines the WS-Security improvements and shows how you can upgrade your Web services to WSE 2.0.
The following is a list of WSE 2.0's new or improved security features, which provide new infrastructure services for designing and implementing Web servicesWSE 2.0:
- Authentication of a Web service call against the Windows security
- Role-based security through the use of security tokens (based on the Windows security)
- Signing and encryption of user-defined SOAP headers
- Support for Keberos security tokens
- A policy framework based on WS-Policy
- SOAP messaging over transport channels like TCP
- Support for the development of user-defined transport channels
Versatile Web Services with Choice of Transport Protocols
Web servicesby their very nameimply that they must have something to do with the Web. But that's not completely true. Look more closely at the SOAP specification and you'll recognize that SOAP can be used independently of the transport protocol. But current Web services implementations exchange SOAP messages only through HTTP or HTTPS.
With WSE 2.0, you now can call Web service methods through other transport protocols, such as TCP, SMTP, MSMQ, or even third-party transport protocols. WSE 2.0 ships with the TCP transport channel, enabling the use of SOAP messaging for communication between distributed applications or even through application domains. Microsoft currently suggests using SOAP messaging for publisher/subscriber scenarios because of the loose coupling of both service endpoints. When you implement such a scenario using proprietary communication technologies like DCOM or .NET remoting, you will end up with a tightly coupled systemand such a system is not very easy to scale in the future.
Tightly coupled endpoints are unfortunately not the only disadvantages to using DCOM or .NET remoting. It has other disadvantages as well. Specifically, you cannot use specifications like WS-Security, WS-Policy, WS-Trust, WS-SecureConversation, and all the others through these communication technologies. For example, consider the following scenario: You are buying a book at an online store like Amazon. After adding your favorite books to your shopping cart, you must enter your payment and delivery information. Let's assume that the system creates a SOAP message for this sensitive information and sends it to the payment agency and finally to the parcel service. Is this process secure? Definitely not!
The SOAP message is intended for two so-called intermediaries, but the first intermediary (the payment agency) doesn't have to know anything about the information intended for the second intermediary (the parcel service). With WSE 2.0, you can now ensure that the first intermediary reads only the information intended for it by signing and encrypting the first part of the SOAP message. This procedure ensures that the second intermediary can't read or alter the first part of the SOAP message, which is not intended for it. You currently can't do this with DCOM or .NET remoting--not yet.
But how do you fit this evolution toward service-oriented applications (like the online store) into Microsoft's Web services picture? In the past few years, Microsoft has recognized that its current communication technologies, like DCOM and .NET remoting, are too complex. Furthermore, everyone thought that Web services could be used only in conjunction with HTTP. But do you want to run your critical enterprise applications on a protocol that isn't reliable or stable? Of course not! Exactly for this reason, Microsoft, IBM, and BEA have begun work on the WSA. The foundation of this architecture are the WS-* specifications.