Web Services Security and More, Part 2: The Global XML Web Services Architecture (GXA)
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:
|Security||WS-Security||The Cornerstone of GXA|
|Policy/Trust||WS-Policy||Expressing Enterprise Security Policies|
|WS-SecurityPolicy||Policy-Related Extensions to WS-Security|
|WS-Trust||Managing Trust Relationships|
|WS-Privacy*||Stating Privacy Requirements and Preferences|
|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|
|Messaging||DIME||Direct Internet Message Encapsulation|
|WS-Attachments||Attachments in DIME|
|WS-ReliableMessaging||Reliable Message Delivery|
|WS-Addressing||Addressing Web Services and Messages|
* not yet released
In this article, we will cover the remaining specifications1.
Direct Internet Message Encapsulation: DIME
The future of DIME is uncertain at this time. The reader is referred to the following URL:
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:
- The security token is created by a security token service
- This approach is defined in the WS-Trust specification.
- This approach works when the sender is trusted to always create a new security context token.
- 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>
Page 1 of 5