Web Services Security and More, Part 2: The Global XML Web Services Architecture (GXA)

Introduction

Welcome to Part 2 of our journey through the Global XML Web Services Architecture (GXA). In Part 1 (www.developer.com/services/article.php/2171031), we learned that GXA is an application-level protocol framework built on top of XML and SOAP that provides a consistent model for building infrastructure-level protocols for Web services and applications. By doing so, GXA "fills the gap" in the current Web services stack. We also learned that GXA specifications can be grouped in seven main "concentrations," as shown below:

* not yet released

In Part 1, we covered the following specifications:

• WS-Security
• WS-Policy
• WS-SecurityPolicy
• WS-PolicyAssertions
• WS-PolicyAttachment
• WS-Trust
• WS-Routing
• WS-Referral
• WS-Transaction

In this article, we will cover the remaining specifications¹.

Direct Internet Message Encapsulation: DIME

The future of DIME is uncertain at this time. The reader is referred to the following URL:
http://www.gotdotnet.com/team/dbox/default.aspx?key=2003-04-22T06:50:29Z.

Attachments in DIME: WS-Attachments

The future of WS-Attachments is also uncertain at this time. The reader is referred to the URL presented above for DIME.

Establishing Security Context: WS-SecureConversation

As we discussed in Part 1, the WS-Security specification focuses on a message authentication model that uses authentication mechanisms such as digital signatures and digital certificates. This approach is generally useful for one-way messages—however, it is subject to several forms of attack. For example, what if a private key were somehow compromised? For this reason, parties involved in a multi-message exchange typically establish a mutually authenticated security context in which message exchanges between the parties occur. Rather than exclusively using public/private keys, this approach involves the use of a session key that is used by the parties to encrypt data that is shared between them. This approach is used by Secure Socket Layer (SSL) and Transport Layer Security (TLS), the successor to SSL, and is known as a context authentication model.

WS-SecureConversation introduces context authentication at the SOAP layer. More specifically, WS-SecureConversation builds on WS-Security to allow the establishment of a security context for a message exchange. It also leverages concepts from the WS-Trust specification for the creation and distribution of security tokens. The WS-SecureConversation specification was released in December 2002 by Microsoft, IBM, Verisign, and RSA Security.

Security Context Token

The main entity in the WS-SecureConversation specification is a security context token. As its name implies, a security context token is a token that is used by both parties in a multi-message exchange as part of an established security context—it is also referred to as a "shared secret." The lifetime of a security context token extends throughout the communications session, after which it ceases to exist—hence the tighter security advantage over the message authentication model.

WS-SecureConversation defines a <SecurityContextToken> element within the WS-Security <Security> header that represents a security context. The following example illustrates the use of this element (all namespace declarations in this article are omitted for brevity):

<wsse:Security>
  <wsse:SecurityContextToken>
    <wsu:Identifier>http://securitycontextid.com</wsu:Identifier>
    <wsu:Expires>2002-08-31T13:20:00-05:00</wsu:Expires>
    <wsse:Keys>
      <xenc:EncryptedKey Id="newSharedSecret">
        ...
      </xenc:EncryptedKey>
    </wsse:Keys>
  </wsse:SecurityContextToken>
</wsse:Security>

In the above example, the established security context is identified by the URI shown in the <wsu:Identifier> element. The W3C XML Encryption <xenc:EncryptedKey> element embeds the key that is used as the shared secret.

An alternate mechanism to embedding a key is to refer to a key using a <wsse:SecurityTokenReference> element, as shown below:

<wsse:Security>
  <wsse:SecurityContextToken wsu:Id="MyID">
    <wsu:Identifier>http://securitycontextid.com</wsu:Identifier>
      <wsu:Expires>2002-08-31T13:20:00-05:00</wsu:Expires>
  </wsse:SecurityContextToken>
  <ds:Signature>
        ...
    <ds:KeyInfo>
      <wsse:SecurityTokenReference>
        <wsse:Reference URI="#MyID"/>
      </wsse:SecurityTokenReference>
    </ds:KeyInfo>
  </ds:Signature>
</wsse:Security>

In the preceding example, the signature is based on the security context. This is exhibited by the fact that the <wsse:Reference> element's URI attribute references the ID of the security context token as specified in the <wsse:SecurityContextToken> element.

Establishing Security Context

The WS-SecureConversation specification presents three ways in which a security context can be established:

1. The security token is created by a security token service
• This approach is defined in the WS-Trust specification.
2. The security token is created by one of the communicating parties, and propagated with a message
• This approach works when the sender is trusted to always create a new security context token.
3. The security token is created through negotiation
• This approach is appropriate when participants need to agree on the contents of a security context token.

Security Context Token Request/Response

The mechanisms for requesting and receiving a security context token are defined in the WS-Trust specification. The following XML fragment demonstrates a request for a security context token (note token type of "wsse:SecurityContextToken"):

<wsse:RequestSecurityToken>
    <wsse:TokenType>wsse:SecurityContextToken</wsse:TokenType>
    <wsse:RequestType>wsse:ReqIssue</wsse:RequestType>
</wsse:RequestSecurityToken>

The following is the corresponding response, which includes a security context token and a <wsse:RequestedProofToken> element that is the proof-of-possession associated with the requested security token:

<wsse:RequestSecurityTokenResponse>
  <wsse:RequestedSecurityToken>
    <wsse:SecurityContextToken wsu:Id="NewTokenID">
      <wsu:Identifier>http://securitycontextid.com</wsu:Identifier>
    </wsse:SecurityContextToken>
  </wsse:RequestedSecurityToken>
  <wsse:RequestedProofToken>
    <xenc:EncryptedKey Id="newProofTokenID">
           ...
    </xenc:EncryptedKey>
  </wsse:RequestedProofToken>
</wsse:RequestSecurityTokenResponse>

Derived Keys

The use of derived keys in a multi-message exchange allows a different key to be used for each exchange, further enhancing security. Each successive key is derived from a key that was used on a previous exchange within the communications session. While there exist multiple algorithms for key derivation, WS-SecureConversation defines an algorithm that is a subset of the mechanism defined for TLS in RFC 2246. This algorithm uses a pseudorandom function called P_SHA-1 (pseudorandom functions are commonly used for encryption, key generation, message-authentication and challenge-response protocols). Both parties use this function to generate shared keys as needed. This function is of the following format:

    P_SHA1 (secret, label + seed)

where secret is the shared secret, label is the concatenation of the client's and service's labels (as defined in their respective policies), and seed is the concatenation of the initiator's and receiver's exchanged nonce values.

The <DerivedKeyToken> element is used to represent a key that is derived from a shared secret. In creating a derived key, the requestor can specify which generation of the key to use as the basis for the derivation. The following example represents a derived key based on the 5th generation of the shared secret (note that generations start with 0):

<DerivedKeyToken>
    <SecurityTokenReference>
              ... 
    </SecurityTokenReference>
    <Generation>4</Generation>
</DerivedKeyToken>

If a new key is to be derived based on this derived key, the above <DerivedKeyToken> element would be passed to the P_SHA-1 function as the secret parameter.

Specification Location

The WS-SecureConversation specification can be found at
http://msdn.microsoft.com/ws/2002/12/ws-secure-conversation.

Web Services Inspection Language: WS-Inspection

Registry specifications such as Universal Description, Discovery, and Integration (UDDI), and OASIS/ebXML Registry enable the registration and discovery of Web service description documents, such as WSDL documents. Once discovered, these description documents can be utilized in a Web services exchange. The WS-Inspection specification enables the aggregation of such description documents on a single site that is not a registry. In doing so, it allows a site to be inspected for service offerings regardless of the format of the description documents for these service offerings. The WS-Inspection specification was released in 2001 by Microsoft and IBM.

WS-Inspection Document

A WS-Inspection document is essentially a set of pointers to service description documents of various formats. For example, the following WS-Inspection document contains a pointer to a single WSDL document:

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/
                          inspection/">
  <service>
    <description referencedNamespace="http://schemas.xmlsoap.org/
                                             wsdl/"
                 location="http://somewsdldocument.wsdl"/>
  </service>
</inspection>

The following WS-Inspection document references a service description that resides in a UDDI registry:

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/
                          inspection/">
  <service>
    <description referencedNamespace="urn:uddi-org:api">
      <wsiluddi:serviceDescription
                location="http://www.descriptionlocation.com ">
      <wsiluddi:serviceKey>4FA28580-5C39-11D5-9FCF-
                AA3200333F79</wsiluddi:serviceKey>
      </wsiluddi:serviceDescription>
    </description>
  </service>
</inspection>

In the preceding example, the "referencedNamespace" attribute identifies the namespace to which the document belongs. While the above example denotes UDDI, the value would be http://schemas.xmlsoap.org/wsdl for a description that points to a WSDL document. This attribute is provided so that WS-Inspection document consumers can easily retrieve WS-Inspection documents based on this information. Additionally, the "location" attribute provides the actual location of the description document, whereas the value of the <wsiluddi:serviceKey> element is used by a UDDI registry in conjunction with the UDDI "get_serviceDetail" message to retrieve the UDDI service description.

Link Mechanism

WS-Inspection specifies a "link" mechanism by which a WS-Inspection document can reference additional aggregations of service descriptions, such as other WS-Inspection documents. This is shown in the following example (note that the "location" attribute contains the URI of a WS-Inspection document):

<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/
                          inspection/">
  <wsil:link referencedNamespace="http://schemas.xmlsoap.org/wsdl"
             location="uri_of_ws_inspection_document">
</inspection>

This mechanism can be valuable in two ways:

1. It can allow for WS-Inspection documents to processed in a hierarchical manner
• WS-Specification does not specify any sort of pattern or algorithm for doing so—it is left up to the consumer of the links.
2. For UDDI descriptions, the "location" attribute can point to the UDDI registry, thereby alleviating the need to create inspection documents with large numbers of service elements containing only single description elements
• This is a "best of both worlds" approach in which maintenance is easier, while still allowing the information contained in the UDDI registry to be discovered through the WS-Inspection inspection process.

WS-Inspection Document Usage

WS-Inspection specifies two methods of usage for WS-Inspection documents that describe where the documents should be placed and how they should be found:

1. Fixed Name
• A WS-Inspection document named "inspection.wsil" is placed wherever the most common entry points to Web sites and applications deployed on the server may be;
• Consistent file naming allows for easy inspection of sites for available services;
2. Linked
• WS-Inspection documents are "linked" into HTML pages through the use of a META tag whose "name" attribute includes the value "serviceInspection" and whose "content" tag specifies a URI indicating the location of a WS-Inspection document;
• This approach allows for user-defined naming of WS-Inspection documents;

HTML META tags are used to communicate information that a human visitor may not be concerned with but which is "meta" information for the page, such as a page description that can influence the description of the page in search engines. An example of the linked approach is:

<HTML>
  <HEAD>
    <META name="serviceInspection"
          content="firstinspectiondoc.wsil">
    <META name="serviceInspection"
          content="secondinspectiondoc.wsil">
    <META name="serviceInspection"
          content="thirdinspectiondoc.wsil">
  </HEAD>
  <BODY>
   ...
  </BODY>
</HTML>

WSDL Binding

WS-Inspection defines a WSDL 1.1 binding that allows for specific information within WSDL documents to be known to WS-Inspection document consumers. More specifically, the following capabilities are provided:

1. Indication of the types of WSDL bindings that appear in the referenced WSDL document;
2. For WSDL documents that specify multiple services, specification of which WSDL service is being referenced;
3. Indication of whether or not a particular referenced WSDL document is providing endpoint information;

The following is an example of the above capabilities expressed within a single WS-Inspection document:

<inspection>
  <service>
    <description referencedNamespace="http://schemas.xmlsoap.org/
                                             wsdl/"
                 location="http://somewsdldocument.wsdl">
      <silwsdl:reference endpointPresent="true">
        <wsilwsdl:referencedService>ServiceName
                 </wsilwsdl:referencedService>
        <wsilwsdl:implementedBinding>BindingName
                 </wsilwsdl:implementedBinding>
        </wsilwsdl:reference>
    </description>
  </service>
</inspection>

Specification Location

The WS-Inspection specification can be found at msdn.microsoft.com/webservices/understanding/gxa/default.aspx?pull=/library/en-us/dnglobspec/html/ws-inspection.asp.

Reliable Message Delivery: WS-ReliableMessaging

In a message exchange scenario, it is of the utmost importance that the parties involved in the exchange can ensure that their messages are delivered in a reliable manner, including the assurance that "lost" messages can be retransmitted and properly received. These capabilities (and more) are addressed by the WS-ReliableMessaging specification, released in March 2003 by Microsoft, IBM, BEA, and TIBCO.

Reliable Messaging Model

The WS-ReliableMessaging reliable messaging model provides a guarantee that messages sent by an initial sender will be delivered to the ultimate receiver, even in the presence of software component, system, or network failures. As with all GXA specifications, WS-ReliableMessaging integrates with and complements other GXA specifications such as WS-Security and the various policy-related specifications, as well as other Web services specifications. The following figure depicts a simple reliable message exchange involving four entities:

• Initial Sender: The endpoint that sends a message;
• Source: The endpoint that actually transmits the message;
• Destination: The endpoint that receives the message;
• Ultimate Receiver: The endpoint to which a message is finally delivered;

In the above figure, the Initial Sender sends a message for reliable delivery by submitting it to the Source (this is the point at which the reliable guarantee begins). The Source accepts the message and transmits it one or more times to the Destination. The Destination then delivers the message to the Ultimate Receiver (this is the point at which the reliable guarantee ends).

Delivery Assurances

Endpoints that implement the WS-ReliableMessaging protocol provide delivery assurances that act as a policy regarding the number of times a message can be sent, whether duplicate messages are allowed, and whether message order is to be preserved. There are four delivery assurances defined by WS-ReliableMessaging:

1. AtMostOnce
• Messages will be delivered at most once (and possibly not at all) and without duplication;
2. AtLeastOnce
• Every message sent will be delivered at least once (and possibly more than once);
3. ExactlyOnce
• Every message sent will be delivered exactly once (i.e. without duplication);
4. InOrder
• Messages will be delivered in the order in which they were sent;

The "InOrder" delivery assurance can be combined with any of the other three assurances.

An Example: Reliable Message Exchange with Retransmission

The following figure demonstrates how WS-ReliableMessaging handles messages in a case where messages are lost in transit and need to be retransmitted:

Click here for a larger image.

In the above figure, the Source sends three messages—numbers 1, 2, and 3. Because message #3 is the last message in the sequence, it includes a "LastMessage" token (this is the third level from the top of the figure). However, message #2 becomes lost in transit—therefore, the Destination acknowledges receipt of only messages #1 and #3 (this is the fourth level). The Source then retransmits message #2, and requests an acknowledgement (this is the fifth level). Finally, upon receiving message #2, the Destination acknowledges receipt of all three messages.

The concepts presented here will be discussed in further detail below.

Sequences

WS-ReliableMessaging uses an entity called a sequence to track and manage reliable message delivery. A sequence contains information such as a unique identifier, message number (which represents the particular message within the sequence that it is carrying), and a date/time at which the sequence will expire. The following is an example of a sequence:

<wsrm:Sequence>
  <wsu:Identifier>http://sequenceid.com</wsu:Identifier>
  <wsrm:MessageNumber>3</wsrm:MessageNumber>
  <wsrm:LastMessage/>
</wsrm:Sequence>

The preceding example depicts the third and last message of the sequence whose identifier is "http://sequenceid.com" (note the <wsrm:LastMessage> element). So, in the example presented in Figure 2, messages #1, #2, and #3 (respectively) would look as follows:

<wsrm:Sequence>
  <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier>
  <wsrm:MessageNumber>1</wsrm:MessageNumber>
</wsrm:Sequence>

<wsrm:Sequence>
  <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier>
  <wsrm:MessageNumber>2</wsrm:MessageNumber>
</wsrm:Sequence>

<wsrm:Sequence>
  <wsu:Identifier>http://fabrikam123.com/abc</wsu:Identifier>
  <wsrm:MessageNumber>3</wsrm:MessageNumber>
  <wsrm:LastMessage/>
</wsrm:Sequence>

Acknowledgements

In WS-ReliableMessaging, acknowledgements may be transmitted individually (i.e. as individual messages) or included as part of return messages. The timing of acknowledgements can be controlled through policy. An acknowledgement can be sent by a Destination for a single message, or a group of messages within a sequence—the latter approach can be beneficial for bandwidth purposes. Acknowledgement of a group of messages is done by specifying an acknowledgement range that gives the upper and lower (inclusive) message numbers for which an acknowledgement is being provided within a particular sequence.

The following is an example of an acknowledgement:

<wsrm:SequenceAcknowledgment>
  <wsu:Identifier>http://sequenceid.com</wsu:Identifier>
  <wsrm:AcknowledgmentRange Upper="5" Lower="1"/>
</wsrm:SequenceAcknowledgment>

In the above example, messages #1 to #5 (inclusive) of the sequence whose identifier is "http://sequenceid.com" are acknowledged. If one message were lost in transmission (for example, message #3), the acknowledgement would look as follows:

<wsrm:SequenceAcknowledgment>
  <wsu:Identifier>http://sequenceid.com</wsu:Identifier>
  <wsrm:AcknowledgmentRange Upper="2" Lower="1"/>
  <wsrm:AcknowledgmentRange Upper="5" Lower="4"/>
</wsrm:SequenceAcknowledgment>

Policy Assertions

WS-ReliableMessaging introduces several new policy assertions that can be used for the description of messaging-related endpoint policies. Some of these are listed here:

• Delivery Assurance: Described earlier in the article;
• Sequence Expiration: Also described earlier in the article;
• Inactivity Timeout: Specifies (in milliseconds) the amount of time after which an endpoint may consider a sequence to have been terminated due to inactivity;
• Retransmission Interval: Specifies (in milliseconds) the amount of time after which a Source will retransmit a message if no acknowledgement has been received;

Policy assertions can be attached to individual sequences, or to a set of sequences (through the specification of an identifier prefix). WS-ReliableMessaging leverages the WS-PolicyAttachment specification for this capability. In order to attach a policy to an individual sequence, a <wsrm:SequenceRef> element is included within the <wsp:PolicyAttachment> element that specifies the sequence identifier, while the policy is specified within the <wsp:Policy> element. This is shown below:

<wsp:PolicyAttachment>
  <wsp:AppliesTo>
    <wsrm:SequenceRef match="Exact">
      <wsu:Identifier>http://sequence1.com</wsu:Identifier>
    </wsrm:SequenceRef>
  </wsp:AppliesTo>
  <wsp:Policy>
    <wsrm:DeliveryAssurance Value="wsrm:AtMostOnce"
          wsp:Usage="wsp:Required"/>
  </wsp:Policy>
</wsp:PolicyAttachment>

In the preceding example, a delivery assurance policy of "AtMostOnce" is associated with the exact sequence whose identifier is "http://sequence1.com" (note the value of the "match" attribute). This policy could also have been associated with all sequences whose identifier began (for example) with "http://sequence" by specifying the following (changes are in bold):

<wsp:PolicyAttachment>
  <wsp:AppliesTo>
    <wsrm:SequenceRef match="Prefix">
      <wsu:Identifier>http://sequence</wsu:Identifier>
    </wsrm:SequenceRef>
  </wsp:AppliesTo>
  <wsp:Policy>
    <wsrm:DeliveryAssurance Value="wsrm:AtMostOnce"
          wsp:Usage="wsp:Required"/>
  </wsp:Policy>
</wsp:PolicyAttachment>

Specification Location

The WS-ReliableMessaging specification can be found at msdn.microsoft.com/ws/2003/03/ws-reliablemessaging.

Addressing Web Services and Messages: WS-Addressing

The WS-Addressing specification advances current mechanisms for addressing Web services and messages by defining transport-neutral mechanisms for identifying Web service endpoints and securing end-to-end endpoint identification in messages. For the former capability (identifying Web service endpoints), it addresses what are described as "current limits" to the WSDL 1.1 extensibility model through the definition of a lightweight and extensible mechanism to satisfy these limits. For the latter capability (securing end-to-end endpoint identification), it defines a standard representation for message information headers that convey endpoint information.

Endpoint References

WS-Addressing defines a standard representation for endpoint references that incorporates information from a WSDL description as well as policy information. The following are examples of the information that is represented:

• Address: A URI that represents a logical address or identifier for the service endpoint;
• Reference Properties: One or more individual properties that are specific to the endpoint;
• Port type: The port type of the endpoint;
• ServiceName: The <wsdl:service> definition that contains a WSDL description of the endpoint being referenced;
• Policy: A policy that is relevant to the interaction with the endpoint;

The following example illustrates an endpoint reference:

<wsa:EndpointReference xmlns:myns="www.mynamespace.com">
  <wsa:Address>http://www.someendpoint.com</wsa:Address>
  <wsa:ReferenceProperties>
    <myns:SenderID>135790</myns:SenderID>
  </wsa:ReferenceProperties>
  <wsa:PortType>InventoryPortType</wsa:PortType>
  <wsa:ServiceName>InventoryService</wsa:ServiceName>
  <wsp:Policy>
    <wsp:TextEncoding wsp:Usage="wsp:Required"
                      Encoding="iso-8859-5"/>
  </wsp:Policy>
</wsa:EndpointReference>

In the preceding example, the <myns:Sender ID> element contains a value that presumably is used by the endpoint to identify the sender. The example also contains a "Text Encoding" assertion (as defined in WS-PolicyAssertions) that indicates the character encoding that is supported by the endpoint.

Binding Endpoint References to SOAP

SOAP messages addressed to endpoints can be constructed by using endpoint reference information through the use of a SOAP binding specified in the WS-Addressing specification. This binding is defined by the following two rules:

1. For SOAP message destination:
• The "Address" value in the endpoint reference is copied into the <wsa:To> element (which is defined by this specification) the SOAP header;
2. For reference properties:
• Each reference property element becomes a header block in the SOAP message;

By using the earlier endpoint reference definition as a starting point, the header of a SOAP message constructed using this endpoint reference definition and the above binding rules would look as follows:

<S:Header>
      ...
  <wsa:To>http://www.someendpoint.com</wsa:To>
  <myns:SenderID>35790</myns:SenderID>
      ...
</S:Header>

Message Information Headers

In an effort to promote more flexible and dynamic exchange of endpoint information in tightly coupled environments, WS-Addressing defines a family of message information headers that enable uniform addressing of messages in a transport-neutral way. These message information headers convey end-to-end message characteristics, including addressing for source and destination endpoints and message identity. The following are some of the properties that message information headers contain:

• Destination: A URI that is the address of the intended receiver;
• Recipient: The ultimate receiver of the message;
• Source Endpoint: The endpoint from which the message originated;
• Reply Endpoint: The intended receiver for replies to the message;
• Action: A URI that uniquely identifies the semantics implied by the message (recommended to correspond to an abstract WSDL construct such as a message, operation, port type, and so forth that is available at the destination endpoint);
• Relationship: Used to correlate a response message to the message to which it is responding;

The following example illustrates a set of message information headers:

      <S:Header>
    <wsa:RelatesTo>uri_of_another_message</wsa:RelatesTo>
    <wsa:To>http://www.someendpoint.com</wsa:To>
    <wsa:Action>http://www.someendpoint.com/ProcessMessage
    </wsa:Action>
    <wsa:From>http://www.somesender.com</wsa:From>
    <wsa:ReplyTo>http://www.someendpoint.com/user9876</wsa:ReplyTo>
    <wsa:Recipient>http://www.someendpoint.com/user1579
    </wsa:Recipient>
      </S:Header>

The following table cross-references the properties presented above with the element names in the above example:

Specification Location

The WS-Addressing specification can be found at msdn.microsoft.com/ws/2003/03/ws-addressing.

Conclusion

In this article, we have discussed the Global XML Web Services Architecture (GXA). GXA is poised to play a major role in advancing the adoption of Web services through its robust specification of mechanisms for Web services such as security, policy, coordination, federation, and routing. More specifications will be forthcoming for areas such as privacy, federation, and authorization.

About the Author

Joseph Chiusano is a Senior Consultant with Booz Allen Hamilton. His technology background includes such diverse areas as systems architecture, relational database applications design and development, operating system development, and XML consulting. Joseph possesses in-depth knowledge in many aspects of XML and XML-related technologies, including Web services, XML schemas, digital security, XML registries, and XML vocabularies.

Endnote

1 WS-Coordination will not be covered because most aspects of the WS-Coordination specification were covered in Part 1 in describing WS-Transaction. DIME and WS-Attachments will also not be covered, for reasons stated in their sections.