Major Features of the Web Services Enhancements
The Web Services Enhancements (WSE) provides an implementation of the Web services architecture for developers creating Web services using ASP.NET and Microsoft .NET Framework client applications.
The major features of WSE covered in this topic are:
- Securing Web services.
- Policy.
- SOAP messaging.
- Routing SOAP messages.
- Sending attachments with SOAP messages.
Securing Web Services
Web services can be secured today, but limitations exist when it comes to building scalable distributed applications based on Web services. Specifically, it is difficult to build scalable applications that cross security domains. Today, you can secure Web services by having the message sent over a secure transport, such as Secure Sockets Layer (SSL), but that only works when the communication is point-to-point. That is, if the SOAP message must be routed to one or more intermediaries before reaching the ultimate receiver and the entire route uses SSL, then the ultimate receiver still has to communicate with the sender to authenticate the sender of the SOAP message. That scenario is difficult to scale.
One of the ways WSE helps to build scalable distributed applications is by providing an efficient and scalable mechanism to secure Web services. It uses the mechanisms defined in the WS-Security specification to place security credentials in the SOAP message itself. This is done by having a client obtain security credentials from a source that is trusted by both the sender and receiver. When a SOAP message sender sends a SOAP request, those security credentials, which are generically known as security tokens, are then placed in the SOAP message. When the Web server receives the SOAP request, it does not need to make another network request back to either the client's computer or a trusted third party to verify the integrity of the security tokens. This is possible if the security credentials are from a trusted source. Instead, WSE cryptographically verifies that the credentials are authentic before passing execution to the Web service. By not having to go back to the source of the credentials, at least one network request is saved, further improving application scalability.
WSE 2.0 extends the notion of adding security credentials to a SOAP message through its support of the WS-Trust, WS-SecureConversation, and WS-Security Profile for XML-based Tokens specifications. Through this implementation of these specifications, WSE provides a mechanism for issuing lightweight security tokens, called security context tokens, as well as allowing the developer to develop their own security token service that issues other types of security tokens. These security tokens can then be used to communicate with Web services that trust the security token service.
Digitally signing and/or encrypting the SOAP message can further secure Web services. Digital signing of a SOAP message helps secure a Web service by enabling a SOAP message recipient, such as a Web service, to cryptographically verify that a SOAP message has not been altered since it was signed. Encryption of a SOAP message helps secure a Web service by making it highly likely that only the intended Web service reads the contents of the message.
WSE provides three features that contribute to the secure transmission of SOAP messages:
- Security credentials enable the scalable securing of Web services over the complete route a SOAP message takes. This is different from a secure transport, such as SSL, which only secures from one point to another. For details on how to use WSE to add security credentials, see How to: Add Security Credentials to a SOAP Message.
- Digital signing allows a SOAP message recipient to cryptographically verify that a SOAP message has not been altered since it was signed. For details on how to digitally sign SOAP messages using WSE, see Digitally Signing a SOAP Message.
The following graphic illustrates the keys needed by the sender and receiver to both sign a SOAP message and to verify the signature. To sign the SOAP message, the sender needs its private key and for a receiver to verify the signature within a SOAP message it needs the sender's public key.
.gif)
- Encryption makes it highly likely that only the intended recipient can read the contents of a message. Encrypting a SOAP message creates a cryptographic secret that is shared with the intended recipient of the message. For details on how to use WSE to encrypt and decrypt SOAP messages, see Encrypting a SOAP Message.
The following graphic illustrates the keys needed by the sender and receiver to both encrypt and decrypt a SOAP message. To encrypt a SOAP message, the sender needs the receiver's public key, and the receiver needs its private key to decrypt the SOAP message.
.gif)
.gif)
Policy
WSE version 2.0 enables developers to express their message receiving and sending requirements using configuration files. Previously, a SOAP message recipient had to contain code to verify message-receiving requirements, such as whether the SOAP message was digitally signed or encrypted. Likewise, the developer for the SOAP message sender had to know the recipient's message requirements and add code to the SOAP message sender. The problem with this approach is that the developer is still writing code to determine access requirements that should be an administrative task. Now those requirements, known as policy assertions, can be expressed in a configuration file.
When these policy assertions are configured, there is a verification process for outgoing SOAP messages and a policy enforcement process for incoming SOAP messages. Outgoing SOAP messages are verified that they meet the send-side policy assertions by WSE, and when they do not, WSE throws an exception. For incoming SOAP messages, WSE enforces the policy assertions specified in the receive-side policy assertions, such that if a SOAP message doesn't adhere to those polices, the SOAP message is rejected and a SOAP fault is thrown.
WSE has a set of predefined policy assertions, such as the requirement that the body of the SOAP message be signed with an X.509 certificate. In addition, the policy system can be extended to allow for custom policy assertions. For details about setting up policy, see Configuring a Web Service's Policy.
SOAP Messaging
SOAP Messaging in WSE 2.0 is a key part of the new enhanced capabilities. WSE 2.0 provides support for communicating using transports other than just HTTP. Specifically, SOAP Messaging supports sending messages using either the TCP or HTTP protocols asynchronously, or in a request/response manner. And when the TCP transport protocol is used, the SOAP messages can be sent and received without using a Web server. A Web server, which only handles HTTP requests, operates based upon the HTTP specification that states for every HTTP request there is an HTTP response. This request/response model is not always necessary when sending messages; a SOAP message sender might need to send several messages and may not need or expect any return SOAP messages. The SOAP messaging in WSE accommodates this type of message exchange pattern, while still allowing developers to take advantage of the other features of WSE, such as the digital signature and encryption support. For more details about WSE SOAP messaging, see Sending and Receiving SOAP Messages.
Before you deploy an application that sends and receives SOAP messages using the TCP protocol, a security expert should perform a security analysis on the parts of the application that are potentially open to attack. WSE helps mitigate attacks by providing the following configuration elements: <allow> Element, <allowRedirectedResponses> Element, <connectionLimit> Element, <deny> Element, <executionTimeout> Element, <hosts> Element, <idleTimeout> Element, <limits> Element, <maxRequestLength> Element, <receiveTimeout> Element, and <sendTimeout> Element. The <allowRedirectedResponses> Element, <executionTimeout> Element, and <maxRequestLength> Element configuration elements can also be used to help mitigate attacks with SOAP messages sent with other protocols, such as HTTP and HTTPS.
Routing SOAP Messages
A distributed application using WSE can be designed such that the network topology implementing the application is transparent to clients. To set up a transparent network topology, set up an intermediate computer that is configured to run WSE router. Clients then send the SOAP messages to WSE router instead of directly to the Web service. WSE router then delegates the SOAP message to a computer hosting the Web service, which can be changed using a configuration file on the computer hosting WSE router.
The following graphic depicts sending SOAP messages to a WSE router and WSE router delegating the SOAP message to another Web server based on the contents of a referral cache. In this sample, the referral cache is configured to send the SOAP message to Web server B, but the referral cache could be modified to send it to Web server C.
.gif)
One of the benefits of using WSE router with a distributed application is that a computer hosting a Web service can be taken offline for maintenance without modifying either the client code or its configuration. An administrator of the computer hosting WSE router can make all the changes needed to redirect the SOAP messages to another computer. To do so, an administrator prepares a backup computer to be brought online to host the Web service, while the router continues to delegate SOAP messages to the primary computer. Then the administrator prepares a Web.config file that specifies the file containing the referral cache and a new referral cache containing the URL for the backup computer. A referral cache is an XML file containing the ultimate destination for URLs received by the router. Then when the primary computer is taken offline, the Web.config and referral cache are placed on the computer hosting the router. Subsequent SOAP messages are then dynamically routed to the backup computer — all unbeknownst to the client application, which is still sending SOAP messages to the router.
WSE also supports the forwarding of SOAP messages to their recipients based on information indicating an alternative route for a Web service. A recipient of the SOAP message can then dynamically route messages according to the referral without the intervention of an administrator. WSE only supports the forwarding of SOAP messages that are not intended for a computer running WSE router.
For detailed steps on how to route SOAP messages using a transparent network topology, see Routing SOAP Messages with WSE.
Sending Attachments with SOAP Messages
WSE supports the Direct Internet Message Encapsulation (DIME) protocol, which defines a mechanism for passing attachments in a SOAP message. It is often necessary for a Web service to send a large file of text or binary data, such as an image file, in a SOAP message. SOAP messages, by default, are not necessarily a good mechanism for transporting these large files, because they are plain-text XML. To be added to a SOAP message, a file must be serialized into XML, which could be more than double the size of the original file. The DIME protocol solves that problem by defining a mechanism for placing the entire contents of the original file outside the SOAP envelope, eliminating the need to serialize the file into XML.
For detailed steps on how to send attachments with SOAP messages, see How to: Add Attachments to a SOAP Message by Using DIME.