Trust, Access Control, and Rights for Web Services Part 1 - SecurityContextToken (Page 8 of 9 )
<SecurityContextToken> The structure of a WS-SecureConversation is based on the <SecurityContextToken> element. This element is a security token that describes a security context. This is the context that will apply to one or more messages to follow. The structure of <SecurityContextToken> is shown in Listing 9.5.
Listing 9.5 The <SecurityContextToken> Element
<wsse:SecurityContextToken wsu:Id="...">
<wsu:Identifier>...</wsu:Identifier>
<wsu:Created>...</wsu:Created>
<wsu:Expires>...</wsu:Expires>
<wsse:Keys>
<xenc:EncryptedKey Id=" ">...</xenc:EncryptedKey>
<wsse:SecurityTokenReference>...</wsse:SecurityTokenReference>
...
</wsse:Keys>
</wsse:SecurityContextToken>
The elements and attributes used in a <wsse:SecurityContextToken> element are described in the following sections.
<wsu:Identifier> The required <wsu:Identifier> element identifies the security context using a URI. This security context URI must be globally unique to both the sender and recipient.
<wsu:Created> The optional <wsu:Created> element indicates the creation time of the security context. It is typically specified only on the first use of the token.
<wsu:Expires> The optional <wsu:Expires> element indicates the expiration time of the security context according to the requestor's clock. It is typically specified only on the first use of the token.
<Keys> The optional <Keys> element holds the shared secrets of the security context. It is typically specified only on the first use of the token. If no <Keys> element is specified, the shared secret is assumed to be already known and associated with the security context identified by the URI specified in the <Identifier> element.
<xenc:EncryptedKey> The optional <xenc:EncryptedKey> element holds the shared secret of the security context.
<xenc:EncryptedKey/@Id> The optional <xenc:EncryptedKey/@Id> attribute specifies an "ID" for the key. Note that this does not use the wsu:Id attribute because the schema doesn't allow for attribute extensibility.
<SecurityTokenReference> The optional <SecurityTokenReference> element references the shared secret of the security context.
Establishing a Security Context There are three ways to establish a security context:
The security context token can be created by an independent third-party token service.
The security context token can be created by one of the communicating parties and propagated with a message.
The security context token can be created through negotiation.
Security Context Token Created by a Security Token Service The initiator can ask a Security Token Service to create a new security context token. The newly created security context token is distributed to the parties through the protocols defined by WS-SecureConversation and WS-Trust. For this scenario, the initiating party sends a <RequestSecurityToken> request to the token service, and a <RequestSecurityTokenResponse> is returned. The response contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the returned context.
Security Context Token Created by One of the Communicating Parties and Propagated with a Message The initiator can create a security context token and send it to the other parties on a message using the mechanisms described here and in WS-Security. This model works when the sender is trusted to always create a new security context token. For this scenario, the initiating party creates a security context token and issues a signed unsolicited <RequestSecurityTokenResponse> to the other party. The message contains a <SecurityTokenReference> pointing to the new security context token and a <ProofTokenReference> pointing to the "secret" for the security context token. The recipient can then choose whether to accept the security context token.
Security Context Token Created Through Negotiation When participants need to negotiate about the contents of the security context token, such as a shared secret, WS-SecureConversation allows the parties to exchange data to establish the security context. For this scenario, the initiating party sends a <RequestSecurityToken> request to the other party, and a <RequestSecurityTokenResponse> is returned. It is likely that the negotiation (challenge/response) semantics described in WS-Trust will be used. Ultimately (if successful), a final response contains a <SecurityTokenReference> pointing to the new security context and a <ProofTokenReference> pointing to the "secret" for the context.
After the shared secret security context token is established for both parties, it is used within WS-Security to secure each message sent as part of a WS-SecureConversation. This scenario is shown in Listing 9.6.
Listing 9.6 Use of a Shared Secret Security Context in WS-Security as Part of WS-SecureConversation
<?xml version="1.0" encoding="utf-8"?>
<S:Envelope xmlns:S="..." xmlns:ds="..." xmlns:wsse="...">
<S:Header>
...
<wsse:Security>
<wsse:SecurityContextToken wsu:Id="MyID"
<wsu:Identifier>uuid:...</wsu:Identifier>
</wsse:SecurityContextToken>
<ds:Signature>
...
<ds:KeyInfo>
<wsse:SecurityTokenReference>
<wsse:Reference URI="#MyID"/>
</wsse:SecurityTokenReference>
</ds:KeyInfo>
</ds:Signature>
</wsse:Security>
</S:Header>
<S:Body wsu:Id="MsgBody">
<tru:StockSymbol xmlns:tru="http://fabrikam123.com/payloads">
QQQ
</tru:StockSymbol>
</S:Body>
</S:Envelope>
Listing 9.6 is a standard SOAP message, so it begins with a SOAP message header followed by the SOAP body. The SOAP header contains the WS-Security <Security> header block, which contains the security-related information for the message. Inside the WS-Security block is a security token associated with the message inside a <SecurityContextToken> element. A URI within this element specifies the unique ID of the context. The digital signature uses the security context just established—in this case, based on the secret key associated with the context. The contents of the XML Digital signature here are represented with ellipses (...) but would reference the body of the message. The <ds:KeyInfo> element holds the key used for the signature. Not surprisingly, it will be the security context token included in the message and therefore will just refer to the URI that is the unique ID of the context specified earlier.
The body of the message comes next and is shown here with another ellipsis.
Much, if not all, of what is described here will be handled for you by the application server platforms and the development tools that support them. It is important to know what they are doing and why, but the details are hidden behind your development tools.
 This chapter is from Securing Web Services Security with WS-Security, by Jothy Rosenberg and David Remy (Sams, 2004, ISBN: 0672326515). Check it out at your favorite bookstore today.
Buy this book now. |
Next: WS-* Security Specifications for Integration >>
More Security Articles
More By Rosenberg, Remy
/ 8 
