How the WSIT Technologies Work

The following sections provide a high-level description of how the messaage optimization, reliable messaging, and security technologies work.

How Message Optimization Works

Message optimization ensures that web services messages are transmitted over the Internet in the most efficient manner. Because XML is a textual format, binary files must be represented using character sequences before they can be embedded in an XML document. A popular encoding that permits this embedding is known as base64 encoding, which corresponds to the XML Schema data type xsd:base64Binary. In a web services toolkit that supports a binding framework, a value of this type must be encoded before transmission and decoded before binding. The encoding and decoding process is expensive and the costs increase linearly as the size of the binary object increases.

Message optimization enables web service endpoints to identify large binary message payloads, remove the message payloads from the body of the SOAP message, encode the message payloads using an efficient encoding mechanism (effectively reducing the size of the payloads), re-insert the message payloads into the SOAP message as attachments (the file is linked to the SOAP message body by means of an Include tag). Thus, message optimization is achieved by encoding binary objects prior to transmission and then de-encoding them when they reach there final destination.

The optimization process is really quite simple. To effect optimized message transmissions, the sending endpoint checks the body of the SOAP message for XML encoded binary objects that exceed a predetermined size and encodes those objects for efficient transmission over the Internet.

SOAP MTOM, paired with the XML-binary Optimized Packaging (XOP), addresses the inefficiencies related to the transmission of binary data in SOAP documents. Using MTOM and XOP, XML messages are dissected in order to transmit binary files as MIME attachments in a way that is transparent to the application. This transformation is restricted to base64 content in canonical form as defined in XSD Datatypes as specified in XML Schema Part 2: Datatypes Second Edition, W3C Recommendation 28 October 2004.

Thus, the WSIT technology achieves message optimization through an implementation of the MTOM and XOP specifications. With the message optimization feature enabled, small binary objects are sent in-line in the SOAP body. For large binary objects, this becomes quite inefficient, so the binary object is separated from the SOAP body, encoded, sent as an attachment to the SOAP message, and decoded when it reaches its destination endpoint.

How Reliable Messaging Works

When reliable messaging is enabled, messages are grouped into sequences, which are defined by the client's proxies. Each proxy corresponds to a message sequence, which consists of all of the request messages for that proxy. Each message contains a sequence header. The header includes a sequence identifier that identifies the sequence and a unique message number that indicates the order of the message in the sequence. The web service endpoint uses the sequence header information to group the messages and--if the Ordered Delivery option is selected--to process them in the proper order. Additionally, if secure conversation is enabled, each message sequence is assigned its own security context token. The security context token is used to sign the handshake messages that initialize communication between two web service endpoints and subsequent application messages.

Thus, using the Reliable Messaging technology, web service endpoints collaborate to determine which messages in a particular application message sequence arrived at the destination endpoint and which messages require resending. The reliable messaging protocol requires that the destination endpoint return message-receipt acknowledgements that include the sequence identifier and the message number of each message received. If the source determines that a message was not received by the destination, it resends the message and requests an acknowledgement. Once the source has sent all messages for a given sequence and their receipt has been acknowledged by the destination, the source terminates the sequence.

The web service destination endpoint in turn sends the application messages along to the application. If ordered delivery is configured (optional), the destination endpoint reconstructs a complete stream of messages for each sequence in the exact order in which the messages were sent and sends them along to the destination application. Thus, through the use of the reliable messaging protocol, the destination endpoint is able to provide the following "delivery assurances" to the web service application:

Each message is delivered to the destination application at least once.

Each message is delivered to the destination application at most once.

Sequences of messages are grouped by sequence identifiers and delivered to the destination application in the order defined by the message numbers.

Figure 1-7 shows a simplified view of client and web service application message exchanges when the Reliable Messaging protocol is not used.

When the Reliable Messaging protocol is not used, application messages flow over the HTTP connection with no delivery assurances. If messages are lost in transit or delivered out of order, the communicating endpoints have no way of knowing.

Figure 1-8 shows a simplified view of client and web service application message exchanges when reliable messaging is enabled.

With reliable messaging enabled, the Reliable Messaging source module is plugged into the JAX-WS web service client. The source module transmits the application messages and keeps copies of the messages until their receipt is acknowledged by the destination module via the exchange of protocol messages. The destination module acknowledges messages and optionally buffers them for ordered-delivery guarantee. After guaranteeing order, if configured, the destination module allows the messages to proceed through the JAX-WS dispatch for delivery to the endpoint or application destination.

How Security Works

The following sections describe how the WSIT security technologies, security policy, trust, and secure conversation work.

How Security Policy Works

The WSIT Web Service Security Policy implementation builds on the features provided by the Web Service Policy implementation in WSIT. It enables users to use XML elements to specify the security requirements of a web service endpoint, that is, how messages are secured on the communication path between the client and the web service. The web service endpoint specifies the security requirements to the client as assertions (see Figure 1-9).

The security policy model uses the policy specified in the WSDL file for associating policy assertions with web service communication. As a result, whenever possible, the security policy assertions do not use parameters or attributes. This enables first-level, QName-based assertion matching to be done at the framework level without security domain-specific knowledge. The first-level matching provides a narrowed set of policy alternatives that are shared by the client and web service endpoint when they attempt to establish a secure communication path.

Note: A QName is a qualified name, as specified by XML Schema Part2: Datatypes specification, Namespaces in XML, Namespaces in XML Errata. A qualified name is made up of a namespace URI, a local part, and a prefix.

The benefit of representing security requirements as assertions is that QName matching is sufficient to find common security alternatives and that many aspects of security can be factored out and re-used. For example, it may be common that the security mechanism is constant for a web service endpoint, but that the message parts that are protected, or secured, may vary by message action.

Protection assertions: Define the scope of security protection. These assertions identify the message parts that are to be protected and how, that is, whether data integrity and confidentiality mechanisms are to be used.

Conditional assertions: Define general aspects or pre-conditions of the security. These assertions define the relationships within and the characteristics of the environment in which security is being applied, such as the tokens that can be used, which tokens are for integrity or confidentiality protection, and applicable algorithms to use, and so on.

Security binding assertions: Define the security mechanism that is used to provide security. These assertions are logical grouping that defines how the conditional assertions are used to protect the indicated message parts. For example, that an asymmetric token is to be used with a digital signature to provide integrity protection, and that parts are to be encrypted with a symmetric key, which is then encrypted using the public key of the recipient. In its simplest form, the security binding assertions restrict what can be placed in the wsse:Security header and the associated processing rules.

Supporting token assertions: Define the token types and usage patterns that can be used to secure individual operations and/or parts of messages.

Web Services Security and Trust assertions: Define the token referencing and trust options that can be used.

How Trust Works

To establish trust between a client, a Security Token Service, and a web service:

The client establishes an HTTPS connection with the Secure Token Service using one of the following methods:

Username Authentication and Transport Security: The client authenticates to the Security Token Service using a username token. The Security Token Service uses a certificate to authenticate to the Client. Transport security is used for message protection.

Mutual Authentication: Both the client-side and server-side use X509 certificates to authenticate to each other. The client request is signed using Client's X509 certificate, then signed using ephemeral key. The web service signs the response using keys derived from the client's key.

The client sends a RequestSecurityToken message to the Security Token Service.

The Security Token Service sends a Security Assertion Markup Language (SAML) token to the Client.

The client uses the SAML token to authenticate itself to the web service and trust is established.

How Secure Conversation Works

Figure 1-11 shows how the Web Services Secure Conversation technology establishes a secure conversation when the Trust technology is not used.