Java Web Services: Desempenho de WS-SecureConversation

Veja como diferentes pilhas de serviços da Web se comparam no desempenho de WS-SecureConversation

O WS-SecureConversation lhe permite assegurar trocas de mensagem de serviço da Web contínuas com menos gasto adicional de processamento do que WS-Security simples. Neste artigo, aprenderemos a configurar e usar o WS-SecureConversation com as três principais pilhas de™ serviços da Web Java em software livre: Apache Axis2, Metro e Apache CXF. Veremos também como as três pilhas se comparam no desempenho de WS-SecureConversation.

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

Author photoDennis Sosnoski é um consultor e instrutor especializado em XML e serviços da Web baseados em Java. Sua experiência em desenvolvimento de software profissional se estende por mais de 30 anos, sendo que nos últimos 10 focou tecnologias XML e Java do lado do servidor. Dennis é o desenvolvedor líder da estrutura de software livre JiBX XML Data Binding e a estrutura de serviços da Web associada JiBX/WS, assim como um committer na estrutura de serviços da Web Apache Axis2. Também foi um dos membros do Grupo de Especialistas para as especificações JAX-WS 2.0 e JAXB 2.0. O material para a série Serviços da Web Java é baseado nas aulas de treinamento de Dennis.



07/Jul/2010

Sobre esta série

Os serviços de Web são uma parte crucial do papel desempenhado pela tecnologia Java na computação empresarial. Nesta série de artigos, o consultor de serviços de XML e Web Dennis Sosnoski abrange as principais estruturas e tecnologias importantes para desenvolvedores Java que utilizam serviços de Web. Acompanhe a série para se manter informado com relação aos mais recentes desenvolvimentos da área e saber como utilizá-los para auxiliá-lo em seus projetos de programação.

O WS-Security fornece recursos essenciais para tornar seguros os serviços da Web corporativos, mas muitas vezes isso resulta em alto custo de desempenho. Em "WS-Trust e WS-SecureConversation", aprendemos como o WS-SecureConversation se apoia em WS-Security e WS-Trust para tornar seguras as trocas contínuas de mensagens entre cliente e servidor com criptografia simétrica. Neste artigo, aprenderemos a configurar o WS-SecureConversation nas três principais pilhas de serviços da Web em software livre — Apache Axis2, Metro e Apache CXF — e também veremos o impacto sobre o desempenho em comparação com a criptografia assimétrica do WS-Security.

Configurando o WS-SecureConversation

Como mencionamos no artigo anterior, o cliente de uma troca de mensagem do WS-SecureConversation primeiramente se conecta a um terminal de Security Token Service (STS) para estabelecer um contexto de segurança que inclui uma chave de segredo compartilhado. Essa chave de segredo compartilhado é usada então como base para criptografar e/ou assinar mensagens trocadas com o serviço de destino. Esse contexto de segurança é identificado por um Security Context Token (SCT), retornado pelo STS ao cliente. O SCT é incluído pelo cliente em todos os pedidos de serviço como parte da conversa segura, e referenciado pelo serviço em todas as respostas.

Como se dá com o WS-Security simples, a configuração de segurança é definida em um documento de WS-Policy. Quando usamos o WS-SecureConversation: duas configurações de segurança separadas estão presentes na política do serviço, uma para a troca de mensagens com o STS e outra para o serviço de destino. A configuração de segurança STS é aninhada dentro da definição de política do token de conversa segura.

As variações do WS-SecureConversation testadas para este artigo quanto ao desempenho são:

  • Apenas assinatura
  • Apenas criptografia
  • Assinatura e criptografia

Em cada caso, a mesma configuração de segurança STS é usada, com chaves assimétricas usadas para assinar e criptografar o número relativamente pequeno de mensagens trocadas entre o cliente e o STS. A listagem 1 mostra uma versão editada do WS-Policy usada para assinar os testes de desempenho, com a política aplicada à troca de mensagem do STS mostrada em negrito (consulte Download para obter o código de origem completo dos exemplos do artigo):

Listagem 1. WS-Policy para testes de desempenho de assinatura
 <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>

Como se dá com o WS-Security simples, é preciso definir parâmetros de tempo de execução adicionais para lidar com a segurança (como keystores e senhas) de uma maneira dependente da implementação. Usar o WS-SecureConversation também exige WS-Addressing (pelo menos para a conversa entre o cliente e o STS), e ativar o WS-Addressing é outro recurso dependente de implementação. Nas próximas três seções, você verá como cada uma das três pilhas de serviços da Web lida com os parâmetros de tempo de execução de segurança e o uso de WS-Addressing.


Configuração do Axis2

A configuração do cliente Axis2 para WS-SecureConversation é basicamente a mesma que para qualquer tipo de uso de WS-Security. Se a troca de mensagens com o STS usa criptografia assimétrica, o cliente deve incluir um elemento <ramp:RampartConfig> na política que fornece os parâmetros de tempo de execução de segurança. As informações de configuração de Rampart são compartilhadas entre o STS e o próprio serviço.

A listagem 2 mostra a configuração do cliente Rampart usada com os testes de desempenho neste artigo. Essa é a mesma configuração usada em artigos anteriores com exemplos de Axis2 da assinatura e criptografia assimétrica do WS-Security.

Listagem 2. Configuração do cliente Axis2/Rampart na 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>

A listagem 3 mostra o código do cliente Axis2 usado para configurar o Rampart e ativar o WS-Addressing. A configuração do Rampart usa o mesmo código de exemplos anteriores do Axis2, exceto que a linha adicionada mostrada em negrito ativa o WS-Addressing ao acionar o módulo addressing.

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

A configuração do servidor do Axis2 é contida no arquivo META-INF/services.xml do arquivo de serviço (AAR). Como se dá com o cliente Axis2, a configuração básica do Rampart é a mesma usada antes para os exemplos de Axis2 para assinatura e criptografia assimétrica do WS-Security. Mas ativar um STS para o serviço exige alguns acréscimos, como mostrado em negrito na versão editada na listagem 4:

Listagem 4. Acréscimos a services.xml no servidor 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>

O primeiro acréscimo mostrado na listagem 4 é o par de referências a módulo para rahas e addressing. O módulo rahas é apenas um acréscimo de configuração ao suporte básico do Rampart, usado para ativar um STS para o serviço. O módulo addressing ativa o suporte a WS-Addressing, assim como no código do cliente da listagem 3.

O segundo acréscimo à listagem 4 é o elemento e conteúdo <parameter name="sct-issuer-config">. Isso configura o STS para emitir SCTs de determinada maneira. Os comentários no conteúdo são tirados diretamente de um dos exemplos do Rampart; parecem ser a única documentação dessa configuração. Infelizmente, os comentários são incorretos: Em testes reais com Axis2 1.5.1/Rampart 1.5, mudar o valor <keyComputation> não teve nenhum efeito sobre a operação do STS, que sempre insistiu em gerar uma chave diretamente e retorná-la para o cliente. Isso não corresponde à política em uso, que exigia que o cliente e a entropia do servidor fossem combinados para gerar a chave de segredo compartilhado.


Configuração do CXF

Configurar o CXF para WS-SecureConversation é mais direto do que a abordagem do Axis2. No lado do cliente, tudo o que é preciso fazer é adicionar os parâmetros de tempo de execução de segurança ao arquivo cxf.xml usado no cliente. Isso funciona da mesma forma que para os parâmetros usados em WS-Security regular, apenas usando nomes diferentes para os parâmetros (todos terminam com o sufixo .sct). A listagem 5 mostra a versão do cxf.xml usada nos testes para este artigo, com os parâmetros SCT em negrito:

Listagem 5. cxf.xml de 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>

A configuração do lado do servidor também é fácil no CXF, mas exige mudanças no arquivo web.xml que define a configuração de contexto do CXF e no arquivo cxf-servlet.xml que fornece a definição de serviço individual. O arquivo web.xml, mostrado na listagem 6, tem uma linha adicional que faz referência à configuração cxf-extension-addr.xml. Essa referência adicional inclui suporte ao WS-Addressing na configuração do CXF, como exigido para troca de mensagens entre o cliente e o STS (e também usado na troca de mensagem entre o cliente e o serviço real, com a política da listagem 1).

Listagem 6. web.xml do servidor do 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>

A listagem 7 mostra o arquivo de configuração cxf-servlet.xml, com um conjunto de definições de parâmetro de SCT correspondente às mostradas para o cliente na listagem 5:

Listagem 7. cxf-servlet.xml do servidor do 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>

Configuração do Metro

O Metro, como o Axis2, usa acréscimos customizados feitos à política de segurança para passar parâmetros de tempo de execução de segurança. Novamente como no caso do Axis2, os parâmetros são passados para o WS-SecureConversation da mesma forma que para o WS-Security. Diferentemente do Axis2, o Metro não precisa de informações de configuração adicionais do STS no servidor, o que torna a configuração do Metro muito mais simples que a do Axis2.

A listagem 8 mostra uma versão editada do WSDL do lado do cliente com os parâmetros de tempo de execução de segurança do Metro mostrados em negrito:

Listagem 8. WSDL do cliente Metro com 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>

A listagem 9 mostra o WSDL do lado do servidor, novamente com os parâmetros de tempo de execução em negrito:

Listagem 9. WSDL do servidor Metro com 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>

O restante da configuração do STS é tirado diretamente da política comum.


Verificando o desempenho

As comparações de desempenho usam o mesmo código de teste de artigos anteriores, um serviço de recuperação de dados sísmicos. O serviço usa um banco de dados de mais de 93.000 terremotos que ocorreram no mundo todo em um período de vários anos. As solicitações do serviço especificam um intervalo de tempo e um intervalo de coordenadas geográficas, e o serviço retorna todos os terremotos dentro do intervalo especificado. Consulte "O Alto Custo de (WS-)Security" para detalhes completos sobre o aplicativo de teste e um par de mensagens de solicitação-resposta de amostra.

Assim como nos artigos anteriores, dois conjuntos de sequências de solicitações são usados para os testes de desempenho. O primeiro conjunto usa 1.000 solicitações, com parâmetros de consulta ajustados para corresponder a uma pequena porção de todo o banco de dados de terremotos (retornando apenas 816 terremotos correspondentes para as 1.000 solicitações). O segundo conjunto usa 100 solicitações, ajustadas para corresponder a uma porção maior do banco de dados (retornando 176.745 terremotos correspondentes para as 100 solicitações). Essas duas sequências de solicitações enfatizam diferentes características de desempenho das pilhas de serviços da Web. A primeira mostra a rapidez com que as pilhas processam as solicitações com poucos dados e a segunda enfatiza a velocidade de processamento de volumes de dados. Cada sequência de solicitação foi executada várias vezes em diferentes configurações de segurança, com apenas o melhor tempo para cada configuração mantido nos resultados. As configurações de segurança testadas foram:

  • Sem segurança (simples)
  • WS-SecureConversation assinando todos os corpos de mensagem de solicitação/resposta (sign)
  • WS-SecureConversation criptografando todos os corpos de mensagem de solicitação/resposta (encr)
  • WS-SecureConversation assinando e criptografando todos os corpos de mensagem de solicitação/resposta (signencr)

Os testes foram executados em um sistema Linux de 64 bits Mandriva 2009.1 com um processador Athlon X2 5400+ e 4 GB de RAM, usando uma JVM de 32 bits Sun (Oracle) Java 1.6.0_18 (que teve um desempenho ligeiramente melhor em relação à JVM de 64 bits para um determinado tamanho de heap). O código do servidor foi executado em Tomcat 6.0.20, configurado para usar 1024 MB do heap, com o código do cliente usando 512 MB de heap. As versões de pilha de serviço da Web testadas foram:

  • Axis2 1.5.1 com o release 1.5 do Rampart
  • Metro 2.0
  • CXF 2.1.8

Se quiser tentar os testes em seu próprio hardware e sua própria JVM, consulte Download para obter o código.

Resultados do desempenho

A Figura 1 mostra os tempos medidos na série de testes de resposta pequena. Como no caso do conjunto de testes anterior, o Metro é um pouco mais rápido que o Axis2 e o CXF em manipular essas mensagens pequenas ao ser executado sem segurança, e essa vantagem de desempenho é transportada para os testes usando o WS-SecureConversation. No geral, o Metro é cerca de 25 por cento mais rápido que o CXF na série de testes de resposta pequena e cerca de duas vezes mais rápido que o Axis2. (Em todos os gráficos deste artigo, barras mais curtas são melhores porque indicam tempo mais rápido.)

Figura 1. Tempos medidos com pequenas respostas
Measured times with small responses

A Figura 2 mostra os tempos medidos na série de testes de resposta grandes. Aqui o Metro novamente é a mais rápida das pilhas, mas essa vantagem não é tão pronunciada como nos testes de resposta pequena. Nesse caso, o CXF fica basicamente empatado com o Metro em todas as configurações, exceto quando o WS-SecureConversation é usado apenas para assinatura. O Metro e o CXF são muito mais rápidos que o Axis2 em todas as configurações do WS-SecureConversation (mais de 40 por cento mais rápidos).

Figura 2. Tempos medidos com grandes respostas
Measured times with large responses

Vantagem do WS-SecureConversation

Uma vantagem do WS-SecureConversation deve ser um ganho de desempenho pelo uso da criptografia simétrica em vez da criptografia assimétrica. As três figuras a seguir mostram se isso realmente corresponde às expectativas. Elas comparam os tempos de cada teste de execução das pilhas usando WS-Security com chaves privadas e certificados (criptografia assimétrica) e a mesma pilha usando WS-SecureConversation com chave secreta (criptografia simétrica). Os tempos do WS-Security são tirados da "Comparação de desempenho do CXF", executada no mesmo hardware e quase nas mesmas versões das pilhas de serviços da Web. (Apenas a versão do CXF é diferente.) Visto que os tempos de teste do WS-Security não incluíram configuração apenas para criptografia (que não é suportada com o uso de certificados), apenas os tempos para testes de assinatura e de assinatura e criptografia foram comparados.

A Figura 3 compara os tempos do Axis2:

Figura 3. Comparação de desempenho do Axis2
Axis2 performance comparison

A Figura 4 compara os tempos do Metro:

Figura 4. Comparação de desempenho do Metro
Metro performance comparison

A Figura 5 compara os tempos do CXF:

Figura 5. Comparação de desempenho do CXF
CXF performance comparison

As três figuras mostram um padrão similar. Os resultados do teste apenas com assinatura são muito mais rápidos usando a criptografia simétrica do WS-SecureConversation para casos de respostas pequenas, mas essa vantagem se perde quando são retornadas respostas grandes. Os resultados dos testes de assinatura e criptografia mostram um grande ganho de desempenho usando a criptografia simétrica do WS-SecureConversation para o caso de respostas pequenas (mais até do que nos resultados apenas de assinatura) e um ganho significativo, mas consideravelmente menor, em respostas grandes.

O que isso quer dizer? Assinar mensagens sempre envolve pré-processamento para converter XML em uma forma canônica. Depois de isso ter sido feito, o XML é compilado para gerar o valor do hash. Esse valor do hash é o que é finalmente incluído na assinatura real, e a geração da assinatura é a única etapa na qual a criptografia simétrica versus assimétrica é diferente. A criptografia de mensagens, por outro lado, apenas processa todo o XML com poucas modificações.

Isso explica os resultados. Ao assinar um grande número de mensagens pequenas com criptografia assimétrica, a maior parte do seu tempo de processamento é gasta na etapa de assinatura. Se estiver assinando mensagens grandes, muito mais tempo será gasto nas etapas de canonicalização e compilação. A criptografia simétrica sempre será mais rápida que a criptografia assimétrica (para forças basicamente equivalentes), mas no caso de assinatura e criptografia os tempos mesclados basicamente resultam na média de ganhos.


Conclusões

O WS-SecureConversation pode fornecer um ganho substancial de desempenho — mais do que o dobro em testes com mensagens pequenas — para trocas contínuas de mensagens, em comparação com o uso de pares de chave privada/certificados para a criptografia assimétrica do WS-Security. Os benefícios de desempenho podem ser ainda maiores se estivermos autorizando clientes de um serviço, visto que a etapa de autorização pode ser manuseada no processamento do STS em vez de em cada solicitação individual para o serviço.

Para ser de benefício, o WS-SecureConversation exige uma sequência contínua de mensagens por um intervalo relativamente curto de tempo. Se for usado para um serviço que os clientes acessam apenas uma vez, na verdade estará sendo acrescentado muito gasto adicional devido às trocas de mensagens entre o cliente e o STS.

O suporte ao WS-SecureConversation provavelmente também não é tão interoperável quanto o WS-Security simples. Posteriormente, irei explorar esse tópico em mais detalhes nesta série. Mas primeiro, na parte do mês que vem, vou tratar do uso da criptografia simétrica com WS-Security regular.


Download

DescriçãoNomeTamanho
Source code for this articlej-jws16-src.zip4.87MB

Recursos

Aprender

Discutir

  • Envolva-se na comunidade My developerWorks. Entre em contato com outros usuários do developerWorks enquanto explora os blogs, fóruns, grupos e wikis dos desenvolvedores.

Comentários

developerWorks: Conecte-se

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


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

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

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java, Software livre
ArticleID=499532
ArticleTitle=Java Web Services: Desempenho de WS-SecureConversation
publish-date=07072010