November 25, 2014
Hot Topics:

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

  • May 20, 2003
  • By Joseph M. Chiusano, Booz Allen Hamilton
  • Send Email »
  • More Articles »

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:






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
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 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 specifications1.

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>




Page 1 of 5



Comment and Contribute

 


(Maximum characters: 1200). You have characters left.

 

 


Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Sitemap | Contact Us

Rocket Fuel