Servicos Java de la Web : Performance de WS-SecureConversation

Vea cómo los diferentes grupos de los servicios de la Web se comparan con la performance de WS-SecureConversation

WS-SecureConversation le permite a usted asegurar los intercambios de los mensajes en curso de los servicios de la Web con menos gastos fijos de procesamiento que con la sencilla WS-Security. En este artículo, usted aprenderá cómo configurar y utilizar WS-SecureConversation con los tres principales grupos de los servicios Java de la Web:™ Apache Axis2, Metro, y Apache CXF. Usted también verá cómo los tres grupos se comparan con la performance de WS-SecureConversation.

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

Author photoDennis Sosnoski es un consultor y entrenador especializado en servicios web y XML basados en Java. Su experiencia en el desarrollo de software profesional abarca más de 30 años, con los últimos 10 enfocados a tecnologías XML y Java ejecutadas en el servidor. Dennis es el desarrollador principal de la infraestructura JiBX XML Data Binding de fuente abierta y de la infraestructura de servicios web JiBX/WS asociada, así como también un delegado en la infraestructura de servicio web Apache Axis2. También fue uno de los miembros de Grupo Experto para las especificaciones KAX-WS 2.0 y JAXB 2.0. El material para la serie de servicios web de Java está basado en las clases de capacitación de Dennis.



29-07-2011

Información acerca de estas series

Los servicios de la Web son una parte fundamental en el rol de la tecnología de Java en la computación empresarial. En esta serie de artículos, el consultor de los servicios de XML y de la Web, Dennis Sosnoski cubre las principales estructuras y las tecnologías que son importantes para los desarrolladores de Java que utilizan los servicios de la Web. Siga la serie para mantenerse informado acerca de los últimos desarrollos en el área y conocer cómo puede utilizarlos para ayudar a sus proyectos de programación.

WS-Security proporciona los dispositivos esenciales para garantizar servicios empresariales de la Web pero a menudo esto trae aparejado un costo elevado de la performance. En "WS-Trust y WS-SecureConversation," usted aprendió cómo WS-SecureConversation se basa en WS-Security y en WS-Trust para asegurar un intercambio de mensajes actuales entre un cliente y un servidor con un cifrado simétrico. En este artículo, usted aprenderá cómo configurar WS-SecureConversation en los tres grupos principales de servicios Java de la Web de fuente abierta — Apache Axis2, Metro y Apache CXF —, y también verá el impacto en la performance en comparación con el cifrado asimétrico de WS-Security.

Configurar WS-SecureConversation

Como se debatió en el artículo previo, el cliente en un intercambio de mensajes de WS-SecureConversation, primero se conecta con una terminal de Security Token Service (STS) para establecer un contexto de seguridad que incluya una clave secreta compartida. Esta clave secreta compartida es luego utilizada como la base para cifrar y/o firmar los mensajes intercambiados con el servicio de destino. El contexto de seguridad es identificado por un Security Context Token (SCT), devuelto por el STS al cliente. El SCT está incluido por el cliente en todos las solicitudes de servicio como parte de la conversación segura, y al que hace referencia el servicio en todas las respuestas.

Al igual que con la sencilla WS-Security, la configuración de la seguridad es definida en un documento WS-Policy. Cuando utiliza WS-SecureConversation: dos configuraciones de seguridad por separado están presentes en la política para el servicio, una para el intercambio de mensajes con STS y la otra para el servicio de destino. La configuración de la seguridad STS está anidada en la definición de la política del token de conversación segura.

Las variaciones en las pruebas para la performance de WS-SecureConversation para este artículo son:

  • Firma solamente
  • Cifrado solamente
  • Ambos, firma y cifrado

En cada caso, la misma configuración de seguridad STS es utilizada, con las claves asimétricas utilizadas tanto para firmar como para cifrar la cantidad relativamente pequeña de mensajes intercambiados entre el cliente y STS. El Listado 1 muestra una versión editada de WS-Policy utilizada para la firma de las pruebas de la performance, con la política aplicada al intercambio de los mensajes STS que se muestra en negrita (ver Download para obtener el código fuente completo de los ejemplos del artículo):

Listado 1. WS-Policy para la firma de las pruebas de la performance
 <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>

Del mismo modo que lo hicimos con la sencilla WS-Security debemos definir los parámetros adicionales para el tiempo de ejecución a fin de lograr un manejo seguro (tales como los keystores y las contraseñas) en forma dependiente de la implementación. El uso de WS-SecureConversation también requiere WS-Addressing (al menos para la conversación entre el cliente y STS), y al permitir el uso de WS-Addressing tenemos otro dispositivo que depende de la implementación. En las próximas tres secciones usted verá cómo cada uno de los tres grupos de servicios de la Web maneja tanto el uso de los parámetros de seguridad para el tiempo de ejecución así como también el uso de WS-Addressing.


Configuración de Axis2

La configuración del cliente Axis2 para WS-SecureConversation es básicamente la misma que para cualquier tipo de uso de WS-Security. Si el intercambio de los mensajes con STS utiliza el cifrado asimétrico, el cliente debe incluir un elemento <ramp:RampartConfig> en la política que proporcione los parámetros de seguridad para el tiempo de ejecución. La información de la configuración Rampart es compartida entre STS y el servicio mismo.

El listado 2 muestra la configuración del cliente Rampart utilizado con las pruebas de la performance en este artículo. Ésta es la misma configuración que se utilizó en los artículos anteriores con los ejemplos Axis2 de la firma y el cifrado asimétrico de WS-Security.

Listado 2. Configuración del cliente Axis2/Rampart en la política.
<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>

El Listado 3 muestra el código del cliente Axis2 utilizado para configurar Rampart y activar WS-Addressing. La configuración Rampart utiliza el mismo código que en los ejemplos anteriores de Axis2, salvo que la línea agregada que se muestra en negrita activa WS-Addressing involucrando el módulo addressing.

Listado 3. Código del cliente Axis2
    Options options = client.getOptions();
    options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, policy);
    client.engageModule("addressing");
    client.engageModule("rampart");

La configuración del servidor Axis2 se encuentra en el archivo META-INF/services.xml del archivo (AAR) del archivo de servicio. Al igual que con el cliente Axis2, la configuración básica de Rampart es igual a la utilizada anteriormente para los ejemplos de Axis2 de la firma y del cifrado asimétrico de WS-Security. La activación de STS para el servicio requiere algunos agregados, aunque, como se puede ver en negrita en la versión editada en el Listado 4:

Listado 4. Incorporación de services.xml al servidor de Axis2
<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>

la primera incorporación que se muestra en el Listado 4 es el par de referencias a los módulos para rahas y addressing. El módulo rahas es sólo una incorporación a la configuración para el soporte básico de Rampart utilizado para activar un STS para el servicio. El módulo addressing activa el soporte de WS-Addressing, del mismo modo que lo hace en el código del cliente del Listado 3.

La segunda incorporación en el Listado 4 es el elemento y el contenido <parameter name="sct-issuer-config">. Esto configura a STS para emitir SCTs de un modo particular. Los comentarios en el contenido son tomados directamente de uno de los ejemplos de Rampart; ellos parecen ser la única documentación de esta configuración. Desafortunadamente, los comentarios no son exactos: En las pruebas reales con Axis2 1.5.1/Rampart 1.5, al cambiar el valor de <keyComputation>no tuvo ningún efecto en la operación de STS, que siempre insistió en la generación de una clave en forma directa y en devolvérsela al cliente. Esto no coincidió con la política en uso que requería que se combinaran la entropía del cliente y del servidor para generar la clave secreta compartida.


Configuración CXF

La configuración de CXF para WS-SecureConversation es más directa que el enfoque de Axis2. Por el lado del cliente, todo lo que usted necesita hacer es añadir los parámetros de seguridad del tiempo de ejecución al archivo cxf.xml utilizado en el cliente. Esto funciona igual que para los parámetros utilizados con WS-Security normal, simplemente utilizando los diferentes nombres de los parámetros (todos los que terminan con el sufijo .sct). El Listado 5 muestra la versión de cxf.xml utilizada en las pruebas para este artículo, con los parámetros SCT en negrita:

Listado 5. cxf.xml del cliente CXF
<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>

La configuración del lado del servidor es también fácil en CXF pero requiere cambios tanto en el archivo web.xml que define la configuración del contexto de CXF como en el archivo cxf-servlet.xml que brinda la definición de los servicios individuales. El archivo web.xml que se muestra en el Listado 6 tiene una línea añadida que se refiere a la configuración cxf-extension-addr.xml. Esta referencia agregada incluye el soporte de WS Addressing en la configuración de CXF, según sea necesario para el intercambio de mensajes entre el cliente y STS (y también se utiliza en el intercambio de mensajes entre el cliente y el servicio real, con la política del Listado 1)

Listado 6. web.xml del servidor CXF
<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>

En el Listado 7 se muestra el archivo de configuración cxf-servlet.xml, con un conjunto de definiciones de los parámetros de SCT correspondientes a los que se muestran para el cliente en el Listado 5:

Listado 7. cxf-servlet.xml del servidor CXF
<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>

Configuración de Metro

Metro, como Axis2, utiliza las incorporaciones personalizadas a las políticas de seguridad para pasar los parámetros de seguridad del tiempo de ejecución. Un vez más, como Axis2, los parámetros se pasan por WS-SecureConversation del mismo modo que se hace para WS-Security. A diferencia de Axis2, Metro no necesita ninguna información adicional sobre la configuración de STS en el servidor, lo que hace a la configuración de Metro mucho más simple que la de Axis2.

El Listado 8 muestra una versión editada de WSDL del lado del cliente con los parámetros de seguridad de Metro para el tiempo de ejecución que se muestran en negrita:

Listado 8. WSDL del cliente Metro con parámetros
<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>

El Listado 9 muestra a WSDL del lado del servidor, nuevamente con los parámetros del tiempo de ejecución en negrita:

Listado 9. WSDL del servidor Metro con los parámetros
<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>

El resto de la configuración de STS se toma directamente de la política común.


Verificación de la performance

Las comparaciones de la performance utilizan el mismo código de prueba de los artículos anteriores, un servicio de recuperación de datos sísmicos. El servicio utiliza una base de datos de más 93.000 terremotos que ocurrieron en todo el mundo a lo largo de unos años. Las solicitudes al servicio especifican un rango de tiempo y un rango de coordenadas geográficas, y el servicio devuelve todos los terremotos que ocurren dentro de un rango especificado. Vea "The high cost of (WS-)Security" para obtener más información sobre las aplicaciones de prueba y un par de mensajes modelo de solicitud/respuesta.

Al igual que en los artículos anteriores, dos grupos de secuencias de solicitudes son utilizados para las pruebas de la performance. El primer grupo utiliza 1.000 solicitudes, con los parámetros de consulta ajustados para que coincidan con una pequeña porción de toda la base de datos de los terremotos (devolviendo sólo 816 coicidencias de terremotos para las 1.000 solicitudes). El segundo grupo utiliza 100 solicitudes, ajustadas para que coincidan con una porción más grande de la base de datos (devolviendo 176.745 coincidencias de terremotos para las 100 solicitudes). Estas dos secuencias de solicitudes hacen hincapié en las diferentes características de la performance de los grupos de servicios de la Web. La primera muestra la rapidez con la que los grupos procesan las solicitudes con pocos datos, y en la segunda se hace hincapié en la velocidad de procesamiento de los volúmenes de datos. Cada secuencia de las solicitudes se ejecuta varias veces en diferentes configuraciones de seguridad, pero sólo se tiene en cuenta el mejor tiempo logrado en los resultados de cada configuración. Las configuraciones de seguridad probadas fueron:

  • 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)

Las pruebas se ejecutan en un sistema Mandriva 2009.1 64-bit Linux con un procesador Athlon X2 5400+ y 4GB de RAM, utilizando un Sun (Oracle) Java 1.6.0_18 32-bit JVM (que fue levemente mejor en cuanto a la performance que el JVM de 64-bits para un determinado tamaño de heap). El código del servidor se ejecutó en Tomcat 6.0.20, configurado para utilizar 1024MB de heap, con el código del cliente utilizando 512MB de heap. Las versiones de los grupos de servicios de la Web probadas fueron:

  • Axis2 1.5.1 con el release 1.5 de Rampart
  • Metro 2.0
  • CXF 2.1.8

Si usted desea intentar realizar las pruebas en su propio hardware y en JVM, vea Download para obtener el código.

Resultados de la performance

La Figura 1 muestra los tiempos medidos para las series de pruebas de respuestas breves. Como en el el conjunto previo de pruebas, Metro es algo más rápido que Axis2 y CXF en el manejo de estos pequeños mensajes al ejecutarlos sin ninguna seguridad, y esta ventaja en la performance se traslada a las pruebas utilizando WS-SecureConversation. En general, Metro es alrededor de un 25 % más rápido que CXF en la serie de pruebas de respuestas breves, y alrededor de dos veces más veloz que Axis2. (En todos los gráficos de este artículo, las barras más cortas son mejores porque indican los tiempos más veloces.)

Figura 1. Tiempos medidos con respuestas breves
Tiempos medidos con respuestas breves

La Figura 2 muestra los tiempos medidos para las series de pruebas de respuestas extensas. Acá Metro es nuevamente el más veloz de los grupos, pero no es tan contundente como para las pruebas de las respuestas breves. En este caso, CXF está escencialmente ligado a Metro en todas las configuraciones salvo cuando WS-SecureConversation se utiliza para firmar solamente. Tanto Metro como CXF son mucho más veloces que Axis2 en todas las configuraciones de WS-SecureConversation (en más de un 40 por ciento).

Figura 2. Tiempos medidos con respuestas extensas
Tiempos medidos con respuestas extensas

Ventajas de WS-SecureConversation

Una de las ventajas de WS-SecureConversation se supone que es un beneficio que se obtiene en la performance al utilizar el cifrado simétrico en lugar del asimétrico. Las siguientes tres cifras muestran cómo esto en realidad está a la altura de las circunstancias. Ellos comparan los tiempos para cada prueba de ejecución de los grupos que utiliza WS-Security con las claves y los certificados privados (cifrado asimétrico) y el mismo grupo que utiliza WS-SecureConversation con una clave secreta (cifrado simétrico). Los tiempos de WS-Security son tomados de "CXF Performance comparison," ejecutado en el mismo hardware y casi las mismas versiones de grupos de servicios de la Web. (Sólo la versión CXF es diferente.) Debido a que los tiempos de las pruebas de WS-Security no incluyen una configuración de cifrado único (que no es soportado con el uso de certificados), solamente para cuando sea necesario comparar la firma y las pruebas de firma y cifrado.

La Figura 3 compara los tiempos de Axis 2.:

Figura 3. Comparación de la performance de Axis2
Comparación de la performance de Axis2

La Figura 4 compara los tiempos de Metro:

Figura 4. Comparación de la performance de Metro
Comparación de la performance de Metro

La Figura 5 compara los tiempos de CXF:

Figura 5. Comparación de la performance de CXF
Comparación de la performance de CXF

Las tres figuras muestran un patrón similar. Los resultados de las pruebas de firma solamente son mucho más veloces utilizando el cifrado simétrico de WS-SecureConversation para el caso de las respuestas breves, pero esta ventaja se pierde cuando las respuestas extensas son devueltas. Los resultados de las pruebas de firma y cifrado muestran un gran beneficio en la performance utilizando el cifrado simétrico de WS-SecureConversation para los casos de las respuestas breves (incluso aún más que en los resultados de las firmas solamente), un beneficio importante pero considerablemente pequeño para las grandes respuestas.

¿Qué nos indica esto? La firma de los mensajes siempre implica el procesamiento para convertir a XML en una forma canónica. Una vez hecho esto, XML es resumido para generar un valor hash. Este valor hash es el que está finalmente incluido en la firma real, y la generación de la firma es el único paso para que el cifrado simétrico y el asimétrico sean diferentes. El cifrado de los mensajes, por otro lado, procesa todos los XML con muy pocas modificaciones.

Esto explica los resultados. Cuando usted está firmando una gran cantidad de mensajes breves con cifrado asimétrico, la mayor parte del tiempo de procesamiento se pierde en el paso referido a la firma. Si usted está firmando mensajes extensos, se pierde mucho más tiempo en los pasos de la canonicalización y del resumen. El cifrado simétrico será siempre más veloz que el cifrado asimétrico (para cualidades más o menos equivalentes), pero tanto para firmar como para cifrar la combinación de los tiempos escencialmente promedian los beneficios.


Conclusiones

WS-SecureConversation puede proporcionar un beneficio sustancial en la performance — más del doble del obtenido en las pruebas con mensajes breves — para el intercambio de los mensajes en curso, en comparación con la utilización de los pares de claves certificados privados para el cifrado asimétrico de WS-Security. Los beneficios de la performance pueden ser aún mayores si se autoriza a los clientes de un servicio, porque el paso de la autorización puede ser manejado en el procesamiento de STS en lugar de hacerlo en cada solicitud individual al servicio.

Para que sea beneficioso, WS-SecureConversation requiere una secuencia continua de mensajes a través de un período relativamente corto. Si usted lo utiliza para un servicio al cual los clientes acceden sobre una base extraordinaria, en realidad se estará añadiendo muchos gastos adicionales debido a los intercambios de mensajes entre el cliente y STS.

El soporte de WS-SecureConversation probablemente no sea tan interoperable como lo es el de WS-Security simple. Investigaré este tema detenidamente más adelante en esta serie. Pero primero, en en laa entrega del próximo mes trataré el tema del cifrado simétrico con WS-Security normal.


Descargar

DescripciónNombretamaño
Source code for this articlej-jws16-src.zip4.87MB

Recursos

Aprender

Comentar

  • Involúcrese con la comunidad My developerWorks. Conéctese con otros usuarios de developerWorks mientras explora los blogs, foros, grupos y wikis impulsados por los desarrolladores.

Comentarios

developerWorks: Ingrese

Los campos obligatorios están marcados con un asterisco (*).


¿Necesita un IBM ID?
¿Olvidó su IBM ID?


¿Olvidó su Password?
Cambie su Password

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


La primera vez que inicie sesión en developerWorks, se creará un perfil para usted. La información en su propio perfil (nombre, país/región y nombre de la empresa) se muestra al público y acompañará a cualquier contenido que publique, a menos que opte por la opción de ocultar el nombre de su empresa. Puede actualizar su cuenta de IBM en cualquier momento.

Toda la información enviada es segura.

Elija su nombre para mostrar



La primera vez que inicia sesión en developerWorks se crea un perfil para usted, teniendo que elegir un nombre para mostrar en el mismo. Este nombre acompañará el contenido que usted publique en developerWorks.

Por favor elija un nombre de 3 - 31 caracteres. Su nombre de usuario debe ser único en la comunidad developerWorks y debe ser distinto a su dirección de email por motivos de privacidad.

Los campos obligatorios están marcados con un asterisco (*).

(Por favor elija un nombre de 3 - 31 caracteres.)

Al hacer clic en Enviar, usted está de acuerdo con los términos y condiciones de developerWorks.

 


Toda la información enviada es segura.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=90
Zone=tecnologia Java, SOA y servicios web , WebSphere
ArticleID=549085
ArticleTitle=Servicos Java de la Web : Performance de WS-SecureConversation
publish-date=07292011