Java web services: WS-SecureConversation performance

See how different web services stacks compare on WS-SecureConversation performance

WS-SecureConversation lets you secure ongoing web service message exchanges with less processing overhead than plain WS-Security. In this article, you'll learn how to configure and use WS-SecureConversation with the three main open source Java™ web services stacks: Apache Axis2, Metro, and Apache CXF. You'll also see how the three stacks compare on WS-SecureConversation performance.

Dennis Sosnoski, Architecture Consultant and Trainer, Sosnoski Software Solutions, Inc.

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.



22 June 2010

Also available in Chinese Russian Japanese Portuguese Spanish

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-Security provides essential features for securing enterprise web services but often comes with a heavy performance cost. In "WS-Trust and WS-SecureConversation," you learned how WS-SecureConversation builds on WS-Security and WS-Trust to secure ongoing message exchanges between a client and a server with symmetric encryption. In this article, you'll learn how to configure WS-SecureConversation in the three main open source Java web services stacks — Apache Axis2, Metro, and Apache CXF — and also see the impact on performance compared to WS-Security asymmetric encryption.

Configuring WS-SecureConversation

As discussed in the previous article, the client in a WS-SecureConversation message exchange first connects to a Security Token Service (STS) endpoint to establish a security context that includes a shared secret key. This shared secret key is then used as the basis for encrypting and/or signing messages exchanged with the target service. The security context is identified by a Security Context Token (SCT), returned by the STS to the client. The SCT is included by the client in all requests to the service as part of the secure conversation, and referenced by the service in all responses.

As with plain WS-Security, the security configuration is defined in a WS-Policy document. When you use WS-SecureConversation: two separate security configurations are present in the policy for the service, one for the message exchange with the STS and the other for the target service. The STS security configuration is nested inside the policy definition of the secure conversation token.

The variations of WS-SecureConversation performance-tested for this article are:

  • Signing only
  • Encrypting only
  • Both signing and encrypting

In each case, the same STS security configuration is used, with asymmetric keys used both to sign and to encrypt the relatively small number of messages exchanged between the client and the STS. Listing 1 shows an edited version of the WS-Policy used for the signing performance tests, with the policy applied to the STS message exchange shown in bold (see Download to get the full source code for the article's examples):

Listing 1. WS-Policy for signing performance tests
 <wsp:Policy wsu:Id="SecureConv" ...>
  <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=".../IncludeToken/AlwaysToRecipient">
         <wsp:Policy>
          <sp:RequireDerivedKeys/>
          <sp:BootstrapPolicy>
           <wsp:Policy>
            <sp:AsymmetricBinding>
             <wsp:Policy>
              <sp:InitiatorToken>
               <wsp:Policy>
                <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
                 <wsp:Policy>
                  <sp:RequireThumbprintReference/>
                 </wsp:Policy>
                </sp:X509Token>
               </wsp:Policy>
              </sp:InitiatorToken>
              <sp:RecipientToken>
               <wsp:Policy>
                <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToInitiator">
                 <wsp:Policy>
                  <sp:RequireThumbprintReference/>
                 </wsp:Policy>
                </sp:X509Token>
               </wsp:Policy>
              </sp:RecipientToken>
              <sp:AlgorithmSuite>
               <wsp:Policy>
                <sp:TripleDesRsa15/>
               </wsp:Policy>
              </sp:AlgorithmSuite>
              <sp:Layout>
               <wsp:Policy>
                <sp:Strict/>
               </wsp:Policy>
              </sp:Layout>
              <sp:IncludeTimestamp/>
              <sp:OnlySignEntireHeadersAndBody/>
             </wsp:Policy>
            </sp:AsymmetricBinding>
            <sp:SignedParts>
             <sp:Body/>
             <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/>
             ...
             <sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/>
            </sp:SignedParts>
            <sp:EncryptedParts>
             <sp:Body/>
            </sp:EncryptedParts>
            <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>
      <sp:Layout>
       <wsp:Policy>
        <sp:Strict/>
       </wsp:Policy>
      </sp:Layout>
     </wsp:Policy>
    </sp:SymmetricBinding>
    <sp:SignedParts>
     <sp:Body/>
    </sp:SignedParts>
   </wsp:All>
  </wsp:ExactlyOne>
 </wsp:Policy>

As with plain WS-Security, additional run-time parameters for the security handling (such as keystores and passwords) must be defined in an implementation-dependent manner. Using WS-SecureConversation also requires WS-Addressing (at least for the conversation between the client and the STS), and enabling WS-Addressing is another implementation-dependent feature. In the next three sections, you'll see how each of the three web services stacks handles both the security run-time parameters and WS-Addressing use.


Axis2 configuration

Axis2 client configuration for WS-SecureConversation is essentially the same as for any type of WS-Security usage. If the message exchange with the STS uses asymmetric encryption, the client must include a <ramp:RampartConfig> element in the policy providing the security run-time parameters. Rampart configuration information is shared between the STS and the service itself.

Listing 2 shows the Rampart client configuration used with the performance tests in this article. This is the same configuration used in earlier articles with Axis2 examples of WS-Security asymmetric signing and encrypting.

Listing 2. Axis2/Rampart client configuration in policy
<wsp:Policy ...>
  <wsp:ExactlyOne>
   <wsp:All>
    ...
    <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"> 
      <ramp:user>clientkey</ramp:user>
      <ramp:encryptionUser>serverkey</ramp:encryptionUser>
      <ramp:passwordCallbackClass
        >com.sosnoski.ws.seismic.adb.PWCBHandler</ramp:passwordCallbackClass>
      
      <ramp:signatureCrypto>
        <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type"
            >JKS</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.file"
            >client.keystore</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password"
            >nosecret</ramp:property>
        </ramp:crypto>
      </ramp:signatureCrypto>
      
      <ramp:encryptionCrypto>
        <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin">
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type"
            >JKS</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.file"
            >client.keystore</ramp:property>
          <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password"
            >nosecret</ramp:property>
        </ramp:crypto>
      </ramp:encryptionCrypto>
      
    </ramp:RampartConfig>

   </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

Listing 3 shows the Axis2 client code used to configure Rampart and activate WS-Addressing. The Rampart configuration uses the same code as in earlier Axis2 examples, except that the added line shown in bold activates WS-Addressing by engaging the addressing module.

Listing 3. Axis2 client code
    Options options = client.getOptions();
    options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, policy);
    client.engageModule("addressing");
    client.engageModule("rampart");

Axis2 server configuration is contained in the META-INF/services.xml file from the service archive (AAR) file. As with the Axis2 client, the basic Rampart configuration is the same as used previously for Axis2 examples of WS-Security asymmetric signing and encrypting. Activating an STS for the service requires some additions, though, as shown in bold in the edited version in Listing 4:

Listing 4. Axis2 server services.xml additions
<serviceGroup>
  <service name="seismic-signencr">
    ...
    <module ref="rampart"/>
    <module ref="rahas"/>
    <module ref="addressing"/>;

    <wsp:Policy xmlns:sp=".../ws-sx/ws-securitypolicy/200702"
        xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
        xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
        wsu:Id="SecureConv">
      <wsp:ExactlyOne>
        <wsp:All>
          <wsap:UsingAddressing
              xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
          <sp:SymmetricBinding>
            ...
          </sp:SymmetricBinding>
          ...

          <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy">
            <ramp:user>serverkey</ramp:user>
            <ramp:encryptionUser>clientkey</ramp:encryptionUser>
            <ramp:passwordCallbackClass
              >com.sosnoski.ws.seismic.adb.PWCBHandler</ramp:passwordCallbackClass>

            <ramp:signatureCrypto>
              ...
            </ramp:signatureCrypto>

            <ramp:encryptionCrypto>
              ...
            </ramp:encryptionCrypto>

          </ramp:RampartConfig>
        </wsp:All>
      </wsp:ExactlyOne>
    </wsp:Policy>

    <parameter name="sct-issuer-config">
      <sct-issuer-config>
        <cryptoProperties>
          <crypto provider="org.apache.ws.security.components.crypto.Merlin">
            <property name="org.apache.ws.security.crypto.merlin.keystore.type"
              >JKS</property>
            <property name="org.apache.ws.security.crypto.merlin.file"
              >server.keystore</property>
            <property name="org.apache.ws.security.crypto.merlin.keystore.password"
              >nosecret</property>
          </crypto>
        </cryptoProperties>
        <addRequestedAttachedRef/>
        <addRequestedUnattachedRef/>

            <!--
               Key computation mechanism
               1 - Use Request Entropy
               2 - Provide Entropy
               3 - Use Own Key
            -->
        <keyComputation>3</keyComputation>

            <!--
               proofKeyType element is valid only if the keyComputation is set to 3
               i.e. Use Own Key

               Valid values are: EncryptedKey & BinarySecret
            -->
        <proofKeyType>BinarySecret</proofKeyType>
      </sct-issuer-config>
    </parameter>

    <parameter name="token-canceler-config">
      <token-canceler-config/>
    </parameter>

  </service>
</serviceGroup>

The first addition shown in Listing 4 is the pair of module references for rahas and addressing. The rahas module is just a configuration addition to the basic Rampart support, used to activate an STS for the service. The addressing module activates WS-Addressing support, just as in the Listing 3 client code.

The second Listing 4 addition is the <parameter name="sct-issuer-config"> element and content. This configures the STS to issue SCTs in a particular manner. The comments in the content are taken directly from one of the Rampart examples; they appear to be the only documentation of this configuration. Unfortunately, the comments are inaccurate: In actual testing with Axis2 1.5.1/Rampart 1.5, changing the <keyComputation> value did not have any effect on the operation of the STS, which always insisted on generating a key directly and returning it to the client. This didn't match the policy in use, which required client and server entropy to be combined to generate the shared secret key.


CXF configuration

Configuring CXF for WS-SecureConversation is more straightforward than the Axis2 approach. On the client side, all you need to do is add the security run-time parameters to the cxf.xml file used on the client. This works the same as for the parameters used with regular WS-Security, just using different parameter names (all ending with the suffix .sct). Listing 5 shows the version of cxf.xml used in the tests for this article, with the SCT parameters in bold:

Listing 5. CXF client cxf.xml
<beans xmlns="http://www.springframework.org/schema/beans"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xmlns:jaxws="http://cxf.apache.org/jaxws"
   xsi:schemaLocation="http://www.springframework.org/schema/beans 
   http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
   http://cxf.apache.org/jaxws 
   http://cxf.apache.org/schemas/jaxws.xsd">

  <jaxws:client name="{http://ws.sosnoski.com/seismic/wsdl}seismic" createdFromAPI="true">
    <jaxws:properties>
      <entry key="ws-security.signature.properties.sct"
          value="client-crypto.properties"/>
      <entry key="ws-security.signature.username.sct" value="clientkey"/>
      <entry key="ws-security.encryption.properties.sct"
          value="client-crypto.properties"/>
      <entry key="ws-security.encryption.username.sct" value="serverkey"/>
      <entry key="ws-security.callback-handler.sct"
          value="com.sosnoski.ws.seismic.cxf.ClientCallback"/>
    </jaxws:properties>
  </jaxws:client>

</beans>

The server-side configuration is also easy in CXF but requires changes to both the web.xml file that defines the CXF context configuration and the cxf-servlet.xml file that gives the individual service definition. The web.xml file, shown in Listing 6, has one added line referencing the cxf-extension-addr.xml configuration. This added reference includes WS-Addressing support in the CXF configuration, as required for the message exchange between the client and the STS (and also used in the message exchange between the client and the actual service, with the Listing 1 policy).

Listing 6. CXF server web.xml
<web-app version="2.4" xmlns="http://java.sun.com/xml/ns/j2ee">
  <display-name>CXFLibrary</display-name>
  <description>CXF Seismic Service</description>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>
      classpath:META-INF/cxf/cxf.xml
      classpath:META-INF/cxf/cxf-extension-soap.xml
      classpath:META-INF/cxf/cxf-servlet.xml 
      classpath:META-INF/cxf/cxf-extension-policy.xml
      classpath:META-INF/cxf/cxf-extension-ws-security.xml
      classpath:META-INF/cxf/cxf-extension-http.xml
      classpath:META-INF/cxf/cxf-extension-addr.xml
     </param-value>
  </context-param>
  <servlet>
    <servlet-name>CXFServlet</servlet-name>
    <servlet-class>org.apache.cxf.transport.servlet.CXFServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>
  <servlet-mapping>
    <servlet-name>CXFServlet</servlet-name>
    <url-pattern>/*</url-pattern>
  </servlet-mapping>
</web-app>

Listing 7 shows the cxf-servlet.xml configuration file, with a set of SCT parameter definitions corresponding to those shown for the client in Listing 5:

Listing 7. CXF server cxf-servlet.xml
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xmlns:soap="http://cxf.apache.org/bindings/soap"
    xsi:schemaLocation="http://www.springframework.org/schema/beans
      http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
      http://cxf.apache.org/jaxws
      http://cxf.apache.org/schemas/jaxws.xsd">

  <jaxws:endpoint id="Processor"
      implementor="com.sosnoski.ws.seismic.cxf.CxfSeismicImpl"
      wsdlLocation="WEB-INF/wsdl/seismic.wsdl"
      address="/">

    <jaxws:properties>
      <entry key="ws-security.signature.properties.sct" 
          value="server-crypto.properties"/>
      <entry key="ws-security.signature.username.sct" value="serverkey"/>
      <entry key="ws-security.encryption.username.sct" value="useReqSigCert"/>
      <entry key="ws-security.callback-handler.sct"
          value="com.sosnoski.ws.seismic.cxf.ServerCallback"/>
    </jaxws:properties>

  </jaxws:endpoint>
</beans>

Metro configuration

Metro, like Axis2, uses custom additions to the security policy to pass security run-time parameters. Again like Axis2, the parameters are passed for WS-SecureConversation in the same way as for WS-Security. Unlike Axis2, Metro needs no additional STS configuration information on the server, which makes the Metro configuration much simpler than Axis2's.

Listing 8 shows an edited version of the client-side WSDL with Metro security run-time parameters shown in bold:

Listing 8. Metro client WSDL with parameters
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ...>
  <wsp:Policy xmlns:sp=".../ws-sx/ws-securitypolicy/200702"
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecureConv">
    <wsp:ExactlyOne>
      <wsp:All>
        <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
        <sp:SymmetricBinding>
          ...
        </sp:SymmetricBinding>
        ...
        <wssc:KeyStore alias="clientkey" keypass="clientpass" location="client.keystore"
            storepass="nosecret" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
            wspp:visibility="private"
            xmlns:wssc="http://schemas.sun.com/2006/03/wss/client"/>
        <wssc:TrustStore location="client.keystore" peeralias="serverkey"
            storepass="nosecret" xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy"
            wspp:visibility="private"
            xmlns:wssc="http://schemas.sun.com/2006/03/wss/client"/>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>
  ...
  <wsdl:service name="SeismicMetro">
    <wsdl:port binding="wns:SeismicBinding" name="seismic">
      <soap:address location="http://localhost:8080/metro-seismic"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

Listing 9 shows the server-side WSDL, again with the run-time parameters in bold:

Listing 9. Metro server WSDL with parameters
<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" ...>
  <wsp:Policy xmlns:sp=".../ws-sx/ws-securitypolicy/200702"
      xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
      xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="SecureConv">
    <wsp:ExactlyOne>
      <wsp:All>
        <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/>
        <sp:SymmetricBinding>
          ...
        </sp:SymmetricBinding>
        ...
        <wsss:KeyStore alias="serverkey"
            keypass="com.sosnoski.ws.seismic.metro.KeystoreAccess"
            location="server.keystore" storepass="nosecret"
            xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" wspp:visibility="private"
            xmlns:wsss="http://schemas.sun.com/2006/03/wss/server"/>
        <wsss:TrustStore location="server.keystore" storepass="nosecret"
            xmlns:wspp="http://java.sun.com/xml/ns/wsit/policy" wspp:visibility="private"
            xmlns:wsss="http://schemas.sun.com/2006/03/wss/server"/>
      </wsp:All>
    </wsp:ExactlyOne>
  </wsp:Policy>
  ...
  <wsdl:service name="SeismicMetro">
    <wsdl:port binding="wns:SeismicBinding" name="seismic">
      <soap:address location="http://localhost:8080/metro-seismic"/>
    </wsdl:port>
  </wsdl:service>

</wsdl:definitions>

The rest of the STS configuration is taken directly from the common policy.


Checking performance

The performance comparisons use the same test code as earlier articles, a seismic data retrieval service. The service uses a database of more than 93,000 earthquakes that occurred worldwide over a period of years. Requests to the service specify a time range and a geographic coordinate range, and the service returns all earthquakes within the specified range. See "The high cost of (WS-)Security" for full details of the test application and a sample request/response message pair.

As in the previous articles, two sets of request sequences are used for the performance tests. The first set uses 1,000 requests, with query parameters adjusted to match a small portion of the entire earthquake database (returning 816 matching earthquakes for the 1,000 requests). The second set uses 100 requests, adjusted to match a larger portion of the database (returning 176,745 matching earthquakes for the 100 requests). These two request sequences emphasize different performance characteristics of web services stacks. The first one shows how quickly stacks process requests with little data, and the second emphasizes the speed of processing data volumes. Each request sequence was run multiple times in different security configurations, with only the best time for each configuration kept in the results. The security configurations tested were:

  • No security (plain)
  • WS-SecureConversation signing all request/response message bodies (sign)
  • WS-SecureConversation encrypting all request/response message bodies (encr)
  • WS-SecureConversation signing and encrypting all request/response message bodies (signencr)

The tests were run on a Mandriva 2009.1 64-bit Linux system with an Athlon X2 5400+ processor and 4GB of RAM, using a Sun (Oracle) Java 1.6.0_18 32-bit JVM (which performed slightly better than the 64-bit JVM for a given heap size). The server code was run on Tomcat 6.0.20, configured to use 1024MB of heap, with the client code using 512MB of heap. The web service stack versions tested were:

  • Axis2 1.5.1 with the 1.5 release of Rampart
  • Metro 2.0
  • CXF 2.1.8

If you want to try the tests on your own hardware and JVM, see Download to get the code.

Performance results

Figure 1 shows the measured times for the small-response test series. As in the previous set of tests, Metro is somewhat faster than Axis2 and CXF in handling these small messages when running without any security, and this performance advantage carries over to the tests using WS-SecureConversation. Overall, Metro is about 25 percent faster than CXF in the small-response test series, and about twice as fast as Axis2. (In all of this article's charts, shorter bars are better because they indicate faster times.)

Figure 1. Measured times with small responses
Measured times with small responses

Figure 2 shows the measured times for the large-response test series. Here Metro is again the fastest of the stacks, but it's not nearly as clear-cut as for the small-response tests. In this case, CXF is essentially tied with Metro in all the configurations except when WS-SecureConversation is used for signing only. Both Metro and CXF are much faster than Axis2 across all the WS-SecureConversation configurations (by more than 40 percent).

Figure 2. Measured times with large responses
Measured times with large responses

WS-SecureConversation advantage

One advantage of WS-SecureConversation is supposed to be a performance gain from using symmetric encryption rather than asymmetric encryption. The next three figures show how this actually measures up. They compare the times for each stack running tests using WS-Security with private keys and certificates (asymmetric encryption) and the same stack using WS-SecureConversation with a secret key (symmetric encryption). The WS-Security times are taken from "CXF Performance comparison," run on the same hardware and almost the same versions of the web services stacks. (Only the CXF version is different.) Because the WS-Security test times did not include an encryption-only configuration (which is not supported using certificates), only the times for the signing and signing-and-encrypting tests are compared.

Figure 3 compares the Axis 2 times:

Figure 3. Axis2 performance comparison
Axis2 performance comparison

Figure 4 compares the Metro times:

Figure 4. Metro performance comparison
Metro performance comparison

Figure 5 compares the CXF times:

Figure 5. CXF performance comparison
CXF performance comparison

All three figures show a similar pattern. The signing-only test results are much faster using WS-SecureConversation symmetric encryption for the case of small responses, but this advantage is lost when large responses are returned. The signing-and-encrypting test results show a large performance gain using WS-SecureConversation symmetric encryption for the case of small responses (even more so than in the signing-only results), and a significant but considerably smaller gain for the large responses.

So what does this show? Signing messages always involves preprocessing to convert the XML into a canonical form. Once this has been done, the XML is digested to generate a hash value. This hash value is what's finally included in the actual signature, and generating the signature is the only step for which symmetric vs. asymmetric encryption is any different. Encrypting messages, on the other hand, just processes all the XML with little modification.

This explains the results. When you're signing a large number of small messages with asymmetric encryption, most of your processing time is spent on the signature step. If you're signing large messages, much more time is spent on the canonicalization and digesting steps. Symmetric encryption will always be faster than asymmetric encryption (for roughly equivalent strengths), but for both signing and encrypting the blended times essentially average the gains.


Conclusions

WS-SecureConversation can provide a substantial performance gain — better than double in tests with small messages — for ongoing message exchanges, as compared to using private key-certificate pairs for WS-Security asymmetric encryption. The performance benefits can be even greater if you're authorizing clients of a service, because the authorization step can be handled in the STS processing rather than on each individual request to the service.

To be of any benefit, WS-SecureConversation requires an ongoing sequence of messages over a relatively short span of time. If you use it for a service that clients access on a one-off basis, you'll actually be adding a lot of overhead that's due to message exchanges between the client and the STS.

WS-SecureConversation support is also probably not as interoperable as plain WS-Security. I'll explore that topic in more depth later in this series. But first, in next month's installment, I'll discuss using symmetric encryption with regular WS-Security.


Download

DescriptionNameSize
Source code for this articlej-jws16-src.zip4.87MB

Resources

Learn

Discuss

  • Get involved in the My developerWorks community. Connect with other developerWorks users while exploring the developer-driven blogs, forums, groups, and wikis.

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, Open source
ArticleID=497487
ArticleTitle=Java web services: WS-SecureConversation performance
publish-date=06222010