Introduction
In April 2001, the W3C conducted a Web Services Workshop whose aim was to explore the direction the W3C should take to standardize the emerging Web services architecture. This was a pivotal event in the Web services world, as one of its outcomes was a set of specifications in October 2001 that presented an architecture for the next generation of XML Web Services. This architecture is known as the Global XML Web Services Architecture, (GXA).
For quite some time, there has been a growing need for consistent support of more secure Web services—especially at the levels of inter-enterprise trust and business policy agreement. GXA, as an application-level protocol framework that is built on the foundation of XML and SOAP, helps satisfy this need by providing 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. Because GXA is built on top of SOAP, it is also "transport-neutral"—that is, it does not rely on any application-level transport protocol such as HTTP or SMTP to carry out its specified functionality.
GXA specifications are authored by Microsoft, IBM, Verisign, BEA Systems, RSA Security, and SAP (in various combinations, with Microsoft as an author on all specifications). One of the most valuable aspects of the GXA specifications is that they are designed to be "protocol building blocks" that can be adopted piecemeal or en masse. The GXA specifications also leverage existing specifications such as ITU-T X.509, W3C XML Signature, and W3C XML Encryption for providing required functionality.
Since the initial set of specifications in October 2001, 12 additional GXA specifications have been released—six in December 2002, and two in March 2003. Several more also have been announced as forthcoming. This is indicated in the figure below, which indicates various milestones of GXA:
This article provides highlights from the majority of those specifications that were released up to (and including) December 2002, while those released in March 2003 (WS-ReliableMessaging and WS-Addressing) will be covered in a later article. XML examples that illustrate the main concepts are provided for each covered specification. For brevity, some of these examples denote fragments rather than entire SOAP envelopes.
A Snapshot of the GXA Specifications
The GXA specifications can be grouped in seven main "concentrations." Each concentration is listed below, along with its specifications and a brief description of each specification. Those specifications that have been announced but have not yet been released are marked accordingly.
| Concentration |
Specification |
Brief Description |
| Security |
WS-Security |
The Cornerstone of GXA |
| Policy/Trust |
WS-Policy |
Expressing Enterprise Security Policies |
| |
WS-SecurityPolicy |
Policy-Related Extensions to WS-Security |
| |
WS-PolicyAssertions |
Message-Related Assertions |
| |
WS-PolicyAttachment |
Policies Applied |
| |
WS-Trust |
Managing Trust Relationships |
| |
WS-Privacy* |
Stating Privacy Requirements and Preferences |
| Routing |
WS-Routing |
Application-Level Routing |
| |
WS-Referral |
Dynamic Routing |
| Coordination |
WS-Coordination |
Coordination Requirements |
| |
WS-Transaction |
Transactional Properties |
| Federation |
WS-SecureConversation |
Establishing Security Context |
| |
WS-Federation* |
Constructing Federated Trust Scenarios |
| |
WS-Authorization* |
Specification and Management of Access Policies |
| Inspection |
WS-Inspection |
Web Services Inspection Language |
| Message Encapsulation |
DIME |
Direct Internet Message Encapsulation |
| |
WS-Attachments |
Attachments in DIME |
| * not yet released |
The Cornerstone of GXA: WS-Security
Many Web service interactions today utilize Secure Socket Layer/Transport Layer Security (SSL/TLS) for their transmission security requirements. While this technique works well in point-to-point scenarios, there is a need to maintain secure contexts over multi-point message paths where trust domains need to be crossed (such as between organizations)—that is, to support end-to-end message-level security, not just transport-level security. This need is addressed by the WS-Security specification, which was originally released in October by 2001 by Microsoft, IBM, and Verisign.
Secure Message Exchanges
WS-Security defines a standard set of SOAP extensions that implement message-level integrity and confidentiality for secure message exchanges. WS-Security forms the basis for many other GXA specifications, and thus is considered "The Cornerstone of GXA." This is indicated in the figure below, which shows GXA's placement in the "Web Services Stack:"
Click here for a larger image.
The figure below demonstrates how WS-Security enables the maintenance of a secure context over a multi-point message path. It denotes three Web participants—a "sender" Web service, an "intermediary" Web service, and a "receiver" Web service. Rather than carrying a separate security context from one participant to another (as would be necessary using SSL/TLS), WS-Security allows for the security context to be carried over the entire interaction as a "security umbrella:"
Click here for a larger image.
WS-Security is designed to support a wide variety of security models—i.e. it is designed to support multiple security token formats, multiple trust domains, multiple signature formats, and multiple encryption technologies. This includes existing security models, as well as security models that may be released in the future. Examples of "security tokens" are: a username/password, an X.509 certificate, a Kerberos ticket, or a Security Assertion Markup Language (SAML) assertion.
XML Example: Username/Password
WS-Security defines a <Security> header block within a SOAP message that contains all security-related information. For example, the following <Security> header is used to define direct trust using a username and password (all namespace declarations in this article are omitted for brevity):
<?xml version="1.0" encoding="utf-8"?>
<S:Envelope
<S:Header>
<wsse:Security>
<wsse:UsernameToken wsu:Id="MyID">
<wsse:Username>Zoe</wsse:Username>
<wsse:Password>MyPassword</wsse:Password>
<wsse:Nonce>FKJh...</wsse:Nonce>
<wsu:Created>2001-10-13T09:00:00Z</wsu:Created>
</wsse:UsernameToken> ..... </wsse:Security>
</S:Header>
<S:Body wsu:Id="MsgBody"> ..... </S:Body>
</S:Envelope>
In the above example, the username and password are supplied along with a nonce and timestamp. A nonce is a parameter that varies with time, intended to limit or prevent the unauthorized replay or reproduction of a file (this includes what is common referred to as a "replay attack"). Because the password is clear text, it should be sent on a secured channel; otherwise, it should be obscured by creating a password digest as described in the WS-Security specification—by creating a SHA1 digest using the nonce, timestamp and password).
XML Example: W3C XML Signature
The following example illustrates the use of W3C XML Signature by WS-Security to specify message-level integrity:
<?xml version="1.0" encoding="utf-8"?>
<S:Envelope
<S:Header>
<wsse:Security>
<wsse:BinarySecurityToken
ValueType="wsse:X509v3"
EncodingType="wsse:Base64Binary"
wsu:Id="X509Token">
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
</wsse:BinarySecurityToken>
<ds:Signature>
.....
<ds:SignatureValue>BL8jdfToEb1l/vXcMZNNjPOV...
</ds:SignatureValue> ..... </ds:Signature>
</wsse:Security>
</S:Header>
<S:Body wsu:Id="MsgBody"> ..... </S:Body>
</S:Envelope>
In the above example, the <wsse:BinarySecurityToken> element is used to describe a binary authentication token (such as an X.509 certificate or Kerberos ticket). The "ValueType" attribute above indicates an X.509 certificate, while the "EncodingType" attributes indicates that the encoding format of the certificate is XML Schema base64 encoding. We assume here that the X.509 certificate contains the key that is used to create the digital signature—that is, it is "cryptographically bound" to the signature. In addition to specifying the digital signature, the W3C XML Signature <ds:Signature> element includes several items that are not listed in this example such as canonicalization method, signature method, and digest method.
WS-Security also specifies additional capabilities, such as use of the W3C XML Encryption specification for message confidentiality and message timestamps to indicate the "freshness" of a message.
Specification Location
The WS-Security specification is currently being developed under OASIS, and can be found at http://www.oasis-open.org/committees/wss.
IE 7
Firefox 2.0
