Java web services: WS-Trust and WS-SecureConversation

Learn how WS-SecureConversation improves web service security performance

WS-Security adds enterprise-level security features to SOAP message exchanges, but with a substantial performance cost. WS-Trust builds on WS-Security to provide a way of exchanging security tokens, and WS-SecureConversation builds on WS-Security and WS-Trust to improve performance for ongoing message exchanges. Dennis Sosnoski continues his Java web services column series with an introduction to WS-Trust and WS-SecureConversation.

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Associates Ltd

Author photoDennis Sosnoski is a consultant and trainer specializing in Java-based XML and Web services. His professional software development experience spans more than 30 years, with the last 10 focused on server-side XML and Java technologies. Dennis is the lead developer of the open source JiBX XML Data Binding framework and the associated JiBX/WS Web services framework, as well as a committer on the Apache Axis2 Web services framework. He was also one of the Expert Group members for the JAX-WS 2.0 and JAXB 2.0 specifications. The material for the Java Web Services series is based on Dennis' training classes.



25 May 2010

Also available in Chinese Russian Japanese

WS-Security provides a comprehensive set of security features for web service applications, building on established industry standards for cryptography and for XML encryption and signing. For many applications the features of WS-Security are essential, but they can come at a significant performance cost. Earlier articles in this series investigate how common WS-Security configurations affect performance for the main open source Java™ web services stacks: Apache Axis2, Metro, and Apache CXF.

A major part of the WS-Security performance cost comes from the wide use of asymmetric encryption. As discussed in "Axis2 WS-Security signing and encryption," asymmetric encryption is a useful tool because it works with key pairs. Each key in the pair can be used to encrypt messages that the other key can decrypt. The owner of a key pair can make one key publicly available so that anyone can use it to encrypt messages to the owner securely, and also decrypt messages from the owner (thereby verifying the sender's identity). The downside of asymmetric encryption is that it requires a much larger key size and more processing overhead than simpler symmetric encryption based on a single secret key known only to the parties involved in an exchange.

About this series

Web services are a crucial part of Java technology's role in enterprise computing. In this series of articles, XML and web services consultant Dennis Sosnoski covers the major frameworks and technologies that are important to Java developers using web services. Follow the series to stay informed of the latest developments in the field and aware of how you can use them to aid your programming projects.

WS-SecureConversation is a standard that allows symmetric encryption to be used for ongoing exchanges of messages between a client and a server, eliminating the overhead that asymmetric encryption adds. To support the secure exchange of the secret key information necessary for using symmetric encryption, WS-SecureConversation builds on both WS-Security and another standard, WS-Trust. WS-Trust itself builds on WS-Security, defining an interface for a web service that issues and works with security tokens.

WS-Trust

WS-Trust combines two related functions. The first function is to support working with security tokens — specifically, the issuing, renewing, and canceling of security tokens. The second function is to support brokering trust relationships. These two functions may seem different, but they interrelate in that security tokens must be trusted, and trust must be represented by some form of token.

The core of WS-Trust is a set of messages used to issue, renew, cancel, and validate security tokens. These messages can be exchanged by clients calling a particular type of SOAP web service called a Security Token Service (STS). They can also be passed in other ways (such as in the security headers of a request to another service).

STS basics

An STS is a web service that implements a simple interface defined by the WS-Trust specification. This interface allows clients to use security tokens to submit requests for several types of operations. Because an STS is a web service, WS-Security can be used directly in the request and response messages, and WS-SecurityPolicy can be used to specify the types of credentials to be provided by clients or any other security processing required on the messages.

The most basic operation is that of issuing a new token. Listing 1 shows an edited example of a request to an STS for this purpose, with the various headers removed and only the request body listed. (You'll see a sample including headers later.) The request in Listing 1 is for a particular kind of token called a Security Context Token (SCT), used by WS-SecureConversation:

Listing 1. Requesting a security token from an STS
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    ...
  </soap:Header>
  <soap:Body xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-7059772">
    <wst:RequestSecurityToken
        xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <wst:RequestType>http://.../ws-sx/ws-trust/200512/Issue</wst:RequestType>
      <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
          <wsa:Address>http://localhost:8800/cxf-seismicsc-signencr/</wsa:Address>
        </wsa:EndpointReference>
      </wsp:AppliesTo>
      <wst:Lifetime xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd">
        <wsu:Created>2010-05-12T10:33:22.774Z</wsu:Created>
        <wsu:Expires>2010-05-12T10:38:22.774Z</wsu:Expires>
      </wst:Lifetime>
      <wst:TokenType
      >http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct</wst:TokenType>
      <wst:KeySize>128</wst:KeySize>
      <wst:Entropy>
        <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce"
        >kIYFB/u430k3PlOPfUtJ5A==</wst:BinarySecret>
      </wst:Entropy>
      <wst:ComputedKeyAlgorithm
      >http://.../ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKeyAlgorithm>
    </wst:RequestSecurityToken>
  </soap:Body>
</soap:Envelope>

The Listing 1 request body shows the basic <wst:RequestSecurityToken> element used for most requests to an STS. The required <wst:RequestType> child element identifies the specific type of this request, in this case an Issue request. The rest of the child elements are optional parameters to the Issue request, identifying:

  • The service endpoint to be accessed using the requested token (<wsp:AppliesTo> element)
  • The span of time for which the token is valid (<wst:Lifetime> element)
  • The type of token (<wst:TokenType> element)
  • The requested key size in bits (<wst:KeySize> element)
  • Client-supplied entropy data to be used in generating the secret key (<wst:Entropy> element)
  • The algorithm to be used to generate the secret key (<wst:ComputedKeyAlgorithm> element)

If the STS receiving the request approves of any required client-supplied credentials and agrees to the terms of the request, it returns a security token in the response to the Issue request. Listing 2 shows an example of a successful response to an Issue request, again with the headers removed:

Listing 2. Response with security token from an STS
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    ...
  </soap:Header>
  <soap:Body xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
      wsu:Id="Id-4824957">
    <wst:RequestSecurityTokenResponseCollection
        xmlns:wst="http://docs.oasis-open.org/ws-sx/ws-trust/200512">
      <wst:RequestSecurityTokenResponse>
        <wst:RequestedSecurityToken>
          <wsc:SecurityContextToken
              xmlns:wsc="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512"
              xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
              wsu:Id="sctId-A167EB2B526E0894DA12736604029099">
            <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier>
          </wsc:SecurityContextToken>
        </wst:RequestedSecurityToken>
        <wst:RequestedAttachedReference>
          <wsse:SecurityTokenReference
            xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <wsse:Reference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"
                URI="#sctId-A167EB2B526E0894DA12736604029099"
                ValueType=".../ws-sx/ws-secureconversation/200512/sct"/>
          </wsse:SecurityTokenReference>
        </wst:RequestedAttachedReference>
        <wst:RequestedUnattachedReference>
          <wsse:SecurityTokenReference
            xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd">
            <wsse:Reference xmlns:wsse=".../oasis-200401-wss-wssecurity-secext-1.0.xsd"
            URI="A167EB2B526E0894DA12736604029098"
            ValueType=".../ws-sx/ws-secureconversation/200512/sct"/>
          </wsse:SecurityTokenReference>
        </wst:RequestedUnattachedReference>
        <wst:Lifetime xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd">
          <wsu:Created>2010-05-12T10:33:22.909Z</wsu:Created>
          <wsu:Expires>2010-05-12T10:38:22.909Z</wsu:Expires>
        </wst:Lifetime>
        <wst:RequestedProofToken>
          <wst:ComputedKey
          >http://docs.oasis-open.org/ws-sx/ws-trust/200512/CK/PSHA1</wst:ComputedKey>
        </wst:RequestedProofToken>
        <wst:Entropy>
          <wst:BinarySecret Type="http://docs.oasis-open.org/ws-sx/ws-trust/200512/Nonce"
          >DpkK6qcELTO8dlPdDHMi2A==</wst:BinarySecret>
        </wst:Entropy>
      </wst:RequestSecurityTokenResponse>
    </wst:RequestSecurityTokenResponseCollection>
  </soap:Body>
</soap:Envelope>

The Listing 2 response shows a <wst:RequestSecurityTokenResponseCollection> element wrapping a single <wst:RequestSecurityTokenResponse> element, which in turn wraps the response-token information. Because the request is for an SCT (as shown by the value

<wst:TokenType>http://schemas.xmlsoap.org/ws/2005/02/sc/sct</wst:TokenType>

in the Listing 1 request message), the response provides:

  • The actual SCT (wrapped in the <wst:RequestedSecurityToken> element)
  • Some reference structures (<wst:RequestedAttachedReference> and <wst:RequestedUnattachedReference>)
  • The time span during which the token is valid (<wst:Lifetime> element)
  • A proof token (<wst:RequestedProofToken> element)
  • Server-supplied entropy data to be used in generating the secret key (<wst:Entropy> element)

The contents of the proof token define the shared secret value used as the basis for symmetric encryption. In this case, that shared secret value is generated by combining the entropy values supplied by client and server, using a defined algorithm.

Other options

Besides the Issue request type, you can also make Validate, Renew, and Cancel requests to an STS. These requests all require a previously issued token to be referenced or supplied. They allow the client to validate the token, or request that the valid time span for the token be extended or ended.

Responses from an STS can use the <wst:RequestSecurityTokenResponse> element directly when only a single token is being returned, rather than wrapping it in a <wst:RequestSecurityTokenCollection> element as shown in Listing 2. Requests to an STS can use a <wst:RequestSecurityTokenCollection> element, which wraps any number of <wst:RequestSecurityToken> elements.

WS-Trust also allows for directly transporting security tokens in SOAP message headers, rather than via the STS web service interface. This is the only way to share tokens when a token is obtained from an STS that is not co-located with the service.


WS-SecureConversation

WS-SecureConversation builds on WS-Trust, using an STS to manage an SCT. An SCT represents a context shared between the parties involved in a message exchange, and the information in this shared context allows the parties to use symmetric encryption for securing the messages.

Specifically, the context provides a shared secret value to the parties involved in a message exchange (as seen in the Listing 2 response message). The shared secret can itself be the secret key used for symmetric encryption of messages in the exchange, but the preferred approach is to use the shared secret as a base value for deriving the actual secret keys used in the exchange. This sounds like unnecessary complexity, but the purpose is to make it more difficult for anyone monitoring the message exchange to break the secret keys.

STS and service

WS-SecureConversation in theory can be used with multiparty message exchanges, but the most common usage is for a client communicating with a single server. When used in this configuration, the STS that supplies the SCT to the client is co-located with the server, accessed at the same endpoint address. This means that the web services code on the server needs a way to distinguish between messages intended for the STS and those intended for the service itself; the action used on the request serves that purpose.

Figure 1 illustrates the co-located STS configuration and message exchange:

Figure 1. WS-SecureConversation STS co-located with service
WS-SecureConversation STS co-located with service

When the client wants to begin an exchange of messages with the server, it first contacts the STS and establishes a context. This message, shown as message 1 in Figure 1, specifies the action http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT. The response, message 2, supplies the SCT to the client. This context is then referenced in message 3, which specifies whatever action is associated with the actual service application. The SCT is valid in any successive messages from the client to the service during the time span. Messages 3 and 4 use symmetric encryption based on the shared secret, as do all subsequent messages between the client and service. The service application directly accesses the shared secret from the context held by the STS, using the context reference supplied by the client.

WS-Policy configuration

WS-SecureConversation uses WS-Policy and WS-SecurityPolicy configurations that are similar to those used by the basic WS-Security handling covered in previous articles in this series. A big difference is that when WS-SecureConversation is used, the policy must cover two separate exchanges — that between the client and the STS, and that between the client and the actual service. This is handled in the policy description by using a nested policy for the exchange with the STS, while the main body of the policy applies to the exchange between the client and the service.

Listing 3 shows the policy used for the examples in this article:

Listing 3. Example WS-SecureConversation policy
<wsp:Policy wsu:Id="SecConv"
    xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
  <wsp:ExactlyOne>
    <wsp:All>
      <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
      <sp:SymmetricBinding>
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:SecureConversationToken sp:IncludeToken=".../AlwaysToRecipient">
                <wsp:Policy>
                  <sp:RequireDerivedKeys/>
                  <sp:BootstrapPolicy>
                    <wsp:Policy>
                      <sp:AsymmetricBinding>
                        <wsp:Policy>
                          <sp:InitiatorToken>
                            <wsp:Policy>
                              <sp:X509Token sp:IncludeToken=".../AlwaysToRecipient">
                                <wsp:Policy>
                                  <sp:RequireThumbprintReference/>
                                </wsp:Policy>
                              </sp:X509Token>
                            </wsp:Policy>
                          </sp:InitiatorToken>
                          <sp:RecipientToken>
                            <wsp:Policy>
                              <sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
                                <wsp:Policy>
                                  <sp:RequireThumbprintReference/>
                                </wsp:Policy>
                              </sp:X509Token>
                            </wsp:Policy>
                          </sp:RecipientToken>
                          <sp:AlgorithmSuite>
                            <wsp:Policy>
                              <sp:TripleDesRsa15/>
                            </wsp:Policy>
                          </sp:AlgorithmSuite>
                          <sp:IncludeTimestamp/>
                          <sp:OnlySignEntireHeadersAndBody/>
                        </wsp:Policy>
                      </sp:AsymmetricBinding>
                      <sp:SignedParts>
                        <sp:Body/>
                        <sp:Header Name="To" Namespace=".../addressing"/>
                        <sp:Header Name="From" Namespace=".../addressing"/>
                        <sp:Header Name="FaultTo" Namespace=".../addressing"/>
                        <sp:Header Name="ReplyTo" Namespace=".../addressing"/>
                        <sp:Header Name="MessageID" Namespace=".../addressing"/>
                        <sp:Header Name="RelatesTo" Namespace=".../addressing"/>
                        <sp:Header Name="Action" Namespace=".../addressing"/>
                      </sp:SignedParts>
                      <sp:Trust13>
                        <wsp:Policy>
                          <sp:MustSupportIssuedTokens/>
                          <sp:RequireClientEntropy/>
                          <sp:RequireServerEntropy/>
                        </wsp:Policy>
                      </sp:Trust13>
                    </wsp:Policy>
                  </sp:BootstrapPolicy>
                </wsp:Policy>
              </sp:SecureConversationToken>
            </wsp:Policy>
          </sp:ProtectionToken>
          <sp:AlgorithmSuite>
            <wsp:Policy>
              <sp:Basic128Rsa15/>
            </wsp:Policy>
          </sp:AlgorithmSuite>
        </wsp:Policy>
      </sp:SymmetricBinding>
      <sp:EncryptedParts>
        <sp:Body/>
      </sp:EncryptedParts>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

In Listing 3, the outer policy specifies the use of symmetric encryption (<sp:SymmetricBinding>) to encrypt the body of messages being exchanged (the <sp:EncryptedParts> setting, near the bottom of the listing). Inside the symmetric encryption policy, the <sp:ProtectionToken> and nested <sp:SecureConversationToken> elements say that WS-SecureConversation is to be used to perform the symmetric encryption.

The policy applied when the STS is accessed is defined by the <sp:BootstrapPolicy> (shown in bold) nested inside the <sp:SecureConversationToken>. This policy just specifies signing of message bodies and addressing headers using X.509 certificates, the same type of signing seen in earlier WS-Security articles in this series.

Note that the messages exchanged between the client and the STS are not encrypted when this policy is used. That makes it easy to see what's going on, but for real-world use you'd want to protect the exchange, either by using TLS/SSL transport encryption or WS-Security encryption.

Message exchanges

Listing 4 shows the headers for messages 1 and 2 — the request to the STS and response to the client, respectively. (You've already seen the bodies of these messages, in Listing 1 and Listing 2.)

Listing 4. Headers for STS request and response
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>

    <Action xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-32320445"
      >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RST/SCT</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-2673180"
      >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-5132526"
      >http://localhost:8800/cxf-seismicsc-signencr/</To>
    ...
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsse:BinarySecurityToken xmlns:wsse="...wssecurity-secext-1.0.xsd"
        xmlns:wsu="...wssecurity-utility-1.0.xsd"
        EncodingType="...soap-message-security-1.0#Base64Binary"
        ValueType="...x509-token-profile-1.0#X509v3"
        wsu:Id="CertId-CF15C330C32618BF4912736604028486"
        >MIICo...8/0n33w==</wsse:BinarySecurityToken>
      <wsu:Timestamp xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Timestamp-7">
        <wsu:Created>2010-05-12T10:33:22.831Z</wsu:Created>
        <wsu:Expires>2010-05-12T10:38:22.831Z</wsu:Expires>
      </wsu:Timestamp>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-7059772">
            ...
          </ds:Reference>
          ...
          <ds:Reference URI="#Timestamp-7">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>TYIbt...V0dd8=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-CF15C330C32618BF4912736604028487">
          <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"
            xmlns:wsu="...wssecurity-utility-1.0.xsd"
            wsu:Id="STRId-CF15C330C32618BF4912736604028488">
            <wsse:Reference xmlns:wsse="...wssecurity-secext-1.0.xsd"
            URI="#CertId-CF15C330C32618BF4912736604028486"
            ValueType="...x509-token-profile-1.0#X509v3"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="..." wsu:Id="Id-7059772">
    ...
  </soap:Body>
</soap:Envelope>

soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-33522601"
      >http://docs.oasis-open.org/ws-sx/ws-trust/200512/RSTR/SCT</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-9229531"
      >urn:uuid:d9d1b9b2-a864-446b-ab81-3176f868046e</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-25551189"
      >http://www.w3.org/2005/08/addressing/anonymous</To>
    <RelatesTo xmlns="http://www.w3.org/2005/08/addressing"
      xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-32148925"
      >urn:uuid:24ce01d5-3c17-4df6-ad89-2fc0720152cd</RelatesTo>
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsu:Timestamp xmlns:wsu=
        "http://docs.oasis-open.org/wss/2004/01/oasis-200401-wssecurity-utility-1.0.xsd" 
        wsu:Id="Timestamp-7">
        <wsu:Created>2010-05-12T10:33:22.913Z</wsu:Created>
        <wsu:Expires>2010-05-12T10:38:22.913Z</wsu:Expires>
      </wsu:Timestamp>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-8">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-4824957">
            ...
          </ds:Reference>
          ...
          <ds:Reference URI="#Timestamp-7">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>tr1tx...GY4wk=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-A167EB2B526E0894DA127366040291811">
          <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd"
            xmlns:wsu="...wssecurity-utility-1.0.xsd"
            wsu:Id="STRId-A167EB2B526E0894DA127366040291812">
            <wsse:KeyIdentifier EncodingType="...soap-message-security-1.0#Base64Binary"
            ValueType="...soap-message-security-1.1#ThumbprintSHA1"
            >uYn3PK2wXheN2lLZr4n2mJjoWE0=</wsse:KeyIdentifier>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-4824957">
    ...
  </soap:Body>
</soap:Envelope>

In Listing 4, you can see the certificate being sent from the client to the server, and the certificate reference returned to the client, with the certificate in each direction used to verify the signature of the timestamp and message body. With this policy configuration, the client certificate needs to be trusted by the STS, and the STS certificate must be present in the trust store of the client.

Listing 5 shows a (heavily edited) message exchange between the client and the service using WS-SecureConversation:

Listing 5. Request to the service and response to client
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing">urn:matchQuakes</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</MessageID>
    ...
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsc:SecurityContextToken xmlns:wsc=".../ws-secureconversation/200512"
        xmlns:wsu="...wssecurity-utility-1.0.xsd"
        wsu:Id="sctId-A167EB2B526E0894DA12736604029099">
        <wsc:Identifier>A167EB2B526E0894DA12736604029098</wsc:Identifier>
      </wsc:SecurityContextToken>
      <wsc:DerivedKeyToken xmlns:wsc=".../ws-secureconversation/200512"
        xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="derivedKeyId-9">
        <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd">
          <wsse:Reference xmlns:wsse="..." URI="#sctId-A167EB2B526E0894DA12736604029099"
          ValueType="http://docs.oasis-open.org/ws-sx/ws-secureconversation/200512/sct"/>
        </wsse:SecurityTokenReference>
        <wsc:Offset>0</wsc:Offset>
        <wsc:Length>16</wsc:Length>
        <wsc:Nonce>AyUGKYBNNQstD9EmZUJqlA==</wsc:Nonce>
      </wsc:DerivedKeyToken>
      <wsc:DerivedKeyToken xmlns:wsc=".../ws-secureconversation/200512"
        xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="derivedKeyId-11">
        ...
      </wsc:DerivedKeyToken>
      <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <xenc:DataReference URI="#EncDataId-12"/>
      </xenc:ReferenceList>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-10">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-28812627">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>6NHo8Si1ntZIb2Ivg3S/n1+2uzI=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-CF15C330C32618BF4912736604029689">
          <wsse:SecurityTokenReference xmlns:wsse="..." xmlns:wsu="..."
          wsu:Id="STRId-CF15C330C32618BF49127366040296810">
            <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-9"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-28812627">
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ...>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd">
          <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-11"/>
        </wsse:SecurityTokenReference>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>+krS8lGA...CKSN0fwKR36Q==</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </soap:Body>
</soap:Envelope>

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <Action xmlns="http://www.w3.org/2005/08/addressing"
      >http://ws.sosnoski.com/seismic/wsdl/SeismicInterface/quakeResponse</Action>
    <MessageID xmlns="http://www.w3.org/2005/08/addressing"
      >urn:uuid:c3aa0671-8751-4d6b-8d4c-0e37ce3e394a</MessageID>
    <To xmlns="http://www.w3.org/2005/08/addressing"
      >http://www.w3.org/2005/08/addressing/anonymous</To>
    <RelatesTo xmlns="http://www.w3.org/2005/08/addressing"
      >urn:uuid:c724a446-4375-4e8a-a318-fd3c84510eae</RelatesTo>
    <wsse:Security xmlns:wsse="...wssecurity-secext-1.0.xsd" soap:mustUnderstand="1">
      <wsc:DerivedKeyToken xmlns:wsc="...ws-secureconversation/200512"
      ...
      </wsc:DerivedKeyToken>
      <wsc:DerivedKeyToken xmlns:wsc="...ws-secureconversation/200512"
      ...
      </wsc:DerivedKeyToken>
      <xenc:ReferenceList xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        <xenc:DataReference URI="#EncDataId-12"/>
      </xenc:ReferenceList>
      <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#" Id="Signature-10">
        <ds:SignedInfo>
          ...
          <ds:Reference URI="#Id-10766816">
            ...
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>rU6YoV7BiO0qSQjWw2vwCp9R+fg=</ds:SignatureValue>
        <ds:KeyInfo Id="KeyId-A167EB2B526E0894DA127366040304813">
          <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd" ...>
            <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-9"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </soap:Header>
  <soap:Body xmlns:wsu="...wssecurity-utility-1.0.xsd" wsu:Id="Id-10766816">
    <xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" ...>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>
      <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <wsse:SecurityTokenReference xmlns:wsse="...wssecurity-secext-1.0.xsd">
          <wsse:Reference xmlns:wsse="..." URI="#derivedKeyId-11"/>
        </wsse:SecurityTokenReference>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue>Cl0iUu...TJ6WkZl2A==</xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedData>
  </soap:Body>
</soap:Envelope>

In Listing 5, the SecurityContextToken is included in the headers of each message. And it's referenced by the <wsc:DerivedKeyToken> elements, which give the parameters used to derive the secret keys actually used to sign and encrypt the data.


How much does it help?

Now that you've learned the basics of WS-Trust and WS-SecureConversation, the next article in the series will look into the performance gains provided by WS-SecureConversation on the Apache Axis2, Metro, and Apache CXF web services stacks. Along the way to the performance results, you'll also see the details of configuring WS-SecureConversation on the three stacks.

Resources

Learn

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Java technology on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Java technology, SOA and web services, Security,
ArticleID=491713
ArticleTitle=Java web services: WS-Trust and WS-SecureConversation
publish-date=05252010