Muitas configurações do WS-Security requerem que o cliente e o servidor usem pares de chaves pública/privada, com certificados X.509 para chamar à autoria ou lide da propriedade das chaves públicas. Essa é provavelmente a técnica mais amplamente usada para assinar ou criptografar mensagens com WS-Security e têm algumas vantagens. Especificamente, o certificado de cliente fornece forte verificação de identidade de cliente e fortes garantias de assinatura nas solicitações. Mas também possui inconvenientes, incluindo a sobrecarga do desempenho de criptografia assimétrica e as dores de cabeça de gerenciamento em obter e manter certificados para cada cliente.

"Desempenho de WS-SecureConversation" mostrou como WS-SecureConversation — apesar de ainda estar trabalhando com certificados de clientes — reduz a sobrecarga de desempenho para trocas de mensagens contínuas entre cliente e servidor, usando criptografia simétrica. Neste artigo, você verá como é possível ir uma etapa além e libertar-se da necessidade de certificados de clientes em trocas simples de WS-Security e de WS-SecureConversation.

Criptografando e Assinando sem Certificados de Clientes

Usar criptografia assimétrica com pares de chaves pública/privada para assinar e criptografar mensagens é simples (pelo menos conceitualmente!). . Conforme discutido em "Assinatura e Criptografia Axis2 de WS-Security", sua chave privada é usada para assinar mensagens e a chave pública do destinatário para criptografar mensagens. Qualquer pessoa com acesso à sua chave pública (que está geralmente agrupada em camadas de autenticação na foram de um certificado X.509) pode verificar a assinatura gerada usando sua chave privada, enquanto que somente o proprietário da chave privada correspondente pode decriptografar uma mensagem criptografada com uma chave pública.

Se o cliente não tiver um par de chaves pública/privada, não é possível usar criptografia assimétrica integral. A alternativa é a criptografia simétrica, mas com a criptografia simétrica você deve ter uma chave secreta conhecida somente das partes envolvidas em uma troca de mensagens. Como é possível estabelecer uma chave secreta desse tipo?

A técnica que WS-Security usa é fazer com que o cliente gere um valor de chave secreta, que é então criptografado usando-se a criptografia assimétrica com a chave pública do servidor e integrado na mensagem de solicitação em um token <xenc:EncryptedKey> . O cliente pode usar essa chave secreta (ou uma segurança melhor, uma chave separada derivada da chave secreta) para criptografar e/ou assinar a mensagem de solicitação e o servidor pode fazer o mesmo com a mensagem de resposta. Não há necessidade de o servidor enviar a chave secreta ao cliente, pois o cliente já a tem disponível.

Voltar para parte superior

Configuração de WS-SecurityPolicy

A configuração de WS-Policy/WS-SecurityPolicy para criptografia simétrica usando uma chave gerada pelo cliente é simples. A Listagem 1 mostra a versão usada neste artigo. Esta política especifica criptografia de corpos de mensagens enviados em ambas as direções, usando uma chave secreta gerada pelo cliente.

<wsp:Policy wsu:Id="SymmEncr"
    xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd"
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
    xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
  <wsp:ExactlyOne>
    <wsp:All>
      <sp:SymmetricBinding>
        <wsp:Policy>
          <sp:ProtectionToken>
            <wsp:Policy>
              <sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
                <wsp:Policy>
                  <sp:RequireDerivedKeys/>
                  <sp:RequireThumbprintReference/>
                  <sp:WssX509V3Token10/>
                </wsp:Policy>
              </sp:X509Token>
            </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:Wss11>
        <wsp:Policy>
          <sp:MustSupportRefKeyIdentifier/>
          <sp:MustSupportRefThumbprint/>
          <sp:MustSupportRefEncryptedKey/>
        </wsp:Policy>
      </sp:Wss11>
      <sp:EncryptedParts>
        <sp:Body/>
      </sp:EncryptedParts>
    </wsp:All>
  </wsp:ExactlyOne>
</wsp:Policy>

A asserção <sp:SymmetricBinding> na política da Listagem 1 é o que configura o uso de criptografia simétrica com uma chave secreta. A asserção <sp:X509Token> integrada indica que um certificado X.509 será usado para proteger a transmissão da chave secreta (ou seja, criptografar a chave secreta para transmissão) com o certificado identificado usando uma referência de impressão digital (essencialmente um valor de hash). A geração pelo cliente da chave secreta está implícita no uso de uma asserção <sp:SymmetricBinding> com um token de proteção <sp:X509Token> . As outras asserções de políticas especificam detalhes do algoritmo de criptografia e recursos necessários e, por fim, a asserção <sp:EncryptedParts> indica que o Body SOAP deve ser criptografado usando a chave secreta.

Conforme visto em artigos anteriores, os parâmetros de tempo de execução para a manipulação de segurança (como keystores e senha) devem ser definidos de maneira dependente da implementação. Nesse caso, os parâmetros são simples: o lado do cliente precisa ter acesso a um armazenamento confiável que contém o certificado do servidor e o lado do servidor precisa ter acesso a um keystore que contém a chave privada que corresponde à chave pública no certificado. Consulte artigos anteriores desta série para obter detalhes sobre como os parâmetros são passados para cada uma das pilhas.

Voltar para parte superior

WS-SecureConversation sem Certificados de Clientes

É possível aplicar a mesma técnica que para trabalhar sem certificados de clientes para a troca de mensagens entre o cliente e o Security Token Service (STS) ao usar WS-SecureConversation. (Consulte "WS-Trust e WS-SecureConversation" e "Desempenho de WS-SecureConversation" para obter detalhes de WS-SecureConversation.) Para usar esta abordagem, você basicamente substitui a política da Listagem 1 em <sp:BootstrapPolicy> para a conversa segura. A Listagem 2 mostra como isso funciona, com <sp:SymmetricBinding> mostrado em negrito substituindo <sp:AsymmetricBinding> usado em "Desempenho de WS-SecureConversation":

 <wsp:Policy wsu:Id="SecureConv"
  xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"
  xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"
  xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702">
 <wsp:ExactlyOne>
  <wsp:All>
   <sp:SymmetricBinding>
    <wsp:Policy>
     <sp:ProtectionToken>
      <wsp:Policy>
       <sp:SecureConversationToken
         sp:IncludeToken=".../IncludeToken/AlwaysToRecipient">
        <wsp:Policy>
         <sp:BootstrapPolicy>
          <wsp:Policy>
           <sp:SymmetricBinding>
            <wsp:Policy>
             <sp:ProtectionToken>
              <wsp:Policy>
               <sp:X509Token sp:IncludeToken=".../IncludeToken/Never">
                <wsp:Policy>
                 <sp:RequireDerivedKeys/>
                 <sp:RequireThumbprintReference/>
                 <sp:WssX509V3Token10/>
                </wsp:Policy>
               </sp:X509Token>
              </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:Wss11>
            <wsp:Policy>
             <sp:MustSupportRefKeyIdentifier/>
             <sp:MustSupportRefThumbprint/>
             <sp:MustSupportRefEncryptedKey/>
            </wsp:Policy>
           </sp:Wss11>
           <sp:EncryptedParts>
            <sp:Body/>
           </sp:EncryptedParts>
          </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:EncryptedParts>
    <sp:Body/>
   </sp:EncryptedParts>
  </wsp:All>
 </wsp:ExactlyOne>
</wsp:Policy>

Além de usar uma chave gerada pelo cliente para a troca de mensagens com STS, a política da Listagem 2 também difere daquelas usadas em "Desempenho de WS-SecureConversation", eliminando a asserção <wsap:UsingAddressing> .

Em teoria, essa política deve funcionar em qualquer implementação de WS-Security e WS-SecureConversation. Na prática, alguns problemas ocorreram quando tentei essa configuração com as três pilhas principais de serviços da Web Java de software livre. CXF foi a única pilha que funcionou com a política conforme escrita. Axis2 não funcionou de forma alguma, falhando com exceção do lado do cliente ao processar a mensagem de resposta de STS. Quando alterei a política de autoinicialização de volta para criptografia assimétrica, Axis2 funcionou, mas usou WS-Addressing em todas as mensagens de qualquer forma. Metro também falhou; após incluir novamente <wsap:UsingAddressing>, funcionou com uma chave gerada pelo cliente para criptografia simétrica na troca de mensagens de STS.

Voltar para parte superior

Comparando Desempenho

As comparações de desempenho usam o mesmo código de teste que 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 em todo o mundo por um período de anos. Solicitações ao 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 Segurança (WS-Security)" para obter detalhes integrais do aplicativo de teste e um par de mensagens de solicitação/resposta de amostra.

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 corresponderem a uma pequena parte de todo o banco de dados de terremotos (retornando 816 terremotos correspondentes para as 1.000 solicitações). O segundo conjunto usa 100 solicitações, ajustadas para corresponderem a uma grande parte do banco de dados (retornando 176.745 terremotos correspondentes para as 100 solicitações). Essas duas sequências de solicitação enfatizam diferentes características de desempenho de pilhas de serviços da Web. A primeira mostra com que rapidez as pilhas processam 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 diversas vezes nas diferentes configurações de segurança, somente com o melhor tempo para cada configuração mantido nos resultados. Desta vez, somente duas configurações foram testadas:

• WS-Security com SymmetricBinding criptografando todos os corpos de mensagens de solicitação/resposta (direct)
• WS-SecureConversation criptografando todos os corpos de mensagens de solicitação/resposta (securconv)

A configuração securconv é essencialmente a mesma que a usada em "Desempenho de WS-SecureConversation", a única diferença sendo o uso de SymmetricBinding para a troca de mensagens entre o cliente e STS com Metro e CXF. Como a política SymmetricBinding de STS testada não funcionou com Axis2, a configuração de Axis2 usada para os testes de sincronização foi a mesma que do artigo anterior. A alterar de usar SymmetricBinding para a política de STS é mais para propósitos de demonstração do que para qualquer impacto significativo no desempenho; portanto, essa diferença não é importante nos resultados.

Os testes foram executados em um notebook Mandriva 2009.1 com Linux® de 32 bits cm um processador Turion X2 ZM-85 e 3 GB de RAM, usando uma JVM Sun (Oracle) Java 1.6.0_10 de 32 bits. (Observe que este é um sistema diferente daquele usado para testes de desempenho em artigos anteriores.) O código do servidor foi executado no Tomcat 6.0.20, configurado para usar 1024 MB de 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 de Rampart
• Metro 2.0
• CXF 2.1.8

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

Resultados de Desempenho

A Figura 1 mostra os tempos medidos para a série de testes de resposta pequena. Como em "Desempenho de WS-SecureConversation", Metro é um pouco mais rápido que CXF (aproximadamente 10 por cento) nas sincronizações de WS-SecureConversation. Metro se sai ainda melhor com o uso direto de criptografia simétrica com WS-Security, executando aproximadamente 30% mais rápido. (Em ambos os gráficos deste artigo, barras mais curtas são melhores, pois indicam tempos mais rápidos.)

Os resultados de Axis2 não estão incluídos na Figura 1 devido a um erro que surgiu no curso do teste. O teste de Axis2 começou executando a uma velocidade razoável, mas depois progressivamente teve a velocidade reduzida à medida que o número de iterações aumentou. O tempo total para executar esse teste com Axis2 terminou com mais de 40 vezes o valor de Metro. Esse tipo de redução de velocidade progressiva geralmente indica um problema, como consultas lineares que estão sendo armazenadas por código, neste caso dentro da manipulação de segurança de Axis2 para a criptografia simétrica (possivelmente lidando com as chaves geradas pelo cliente, pois uma nova chave secreta é gerada para cada solicitação).

A Figura 2 mostra os tempos medidos para a série de testes de resposta grande. Aqui, Metro é novamente a mais rápida das pilhas, mas CXF chega perto — a diferente entre as duas é somente de aproximadamente 10 por cento. Axis2 é muito mais lenta do que as outras duas pilhas, como foi o caso nos testes de WS-Security e WS-SecureConversation mostrados nos artigos anteriores.

Esses resultados (exceto para Axis2) correspondem ao que você esperaria ver com base no processamento de segurança que está sendo realizado. Com ambas as configurações de segurança, a criptografia simétrica é usada para as mensagens trocadas entre o cliente e o serviço. A grande diferença entre as duas é que a configuração de criptografia simétrica de WS-Security usa uma nova chave secreta gerada pelo cliente para cada par de mensagens de solicitação/resposta. Esta chave secreta precisa ser criptografada de forma assimétrica usando a chave pública do servidor e enviada como parte da mensagem de solicitação, enquanto que WS-SecureConversation reutiliza uma única chave secreta para muitos pares de mensagens. Isso significa que a configuração de WS-Security inclui sobrecarga significativa por solicitação, o que aparece principalmente nas sincronizações da Figura 1 .

As pilhas não suportam usar criptografia assimétrica de WS-Security somente para criptografar uma mensagem, em vez disso, elas requerem que também seja feita a assinatura. Isso dificulta o fornecimento de qualquer comparação de desempenho direta, mas é possível obter uma ideia da diferença comparando estes gráficos com aqueles de "Desempenho de WS-SecureConversation." O artigo anterior mostrou que a criptografia simétrica de WS-SecureConversation fornece um desempenho consideravelmente melhor do que a criptografia assimétrica, principalmente para criptografar mensagens. Esses resultados mostram que a criptografia simétrica de WS-Security com chaves geradas pelo cliente é praticamente tão rápida quanto WS-SecureConversation, principalmente para mensagens maiores.

Voltar para parte superior

Resumindo

Você viu neste artigo como a criptografia simétrica, usando chaves secretas geradas pelo cliente, pode ser usada para proteger trocas de mensagens sem a necessidade de certificados de clientes. Essa abordagem oferece bom desempenho para trocas de mensagens — quase tão bom quanto WS-SecureConversation — quando as mensagens são relativamente grandes. Se somente algumas mensagens forem trocadas entre um cliente e o servidor, as chaves secretas geradas pelo cliente podem fornecer um desempenho ainda melhor do que as chaves secretas de WS-SecureConversation (pois WS-SecureConversation requer uma troca de mensagens extra entre o cliente e STS).

As chaves secretas geradas pelo cliente também podem ser usadas para assinar mensagens. Apesar de não ser mostrado neste artigo, esse uso de chaves secretas é essencialmente o mesmo que o exemplo de assinatura para WS-SecureConversation discutido em "Desempenho de WS-SecureConversation." Assinar com chaves secretas fornece de forma inerente garantias mais fracas de autenticidade do que assinar com chaves privadas, mas ainda pode ser útil para assegurar que mensagens não foram corrompidas no trânsito.

Os últimos diversos artigos desta série discutiram várias formas de segurança de WS-Security e WS-SecureConversation para serviços da Web, incluindo comparações de desempenho para as três pilhas principais de serviços da Web Java. Cobrirei alguns recursos especializados de WS-Security em artigos futuros, mas por ora está na hora de resumir o foco no desempenho de segurança. O próximo artigo da série detalhará a estrutura de documentos de WS-Policy e as maneiras como as políticas podem ser anexadas a serviços em WSDL, com exemplos de configuração de segurança de ajuste fino para Apache Axis2, Metro e Apache CXF.

Voltar para parte superior

Download

Informações sobre métodos de download

Recursos

Aprender

• Axis2: Axis 2 é uma pilha de serviços da Web de software livre da Apache.
  
  
• Metro: Metro é uma pilha de serviços da Web de software livre que incorpora as implementações de referência mais recentes dos padrões Java JAXB 2.x e JAX-WS 2.x.
  
  
• CXF: CXF é outra pilha de serviços da Web de software livre da Apache Software Foundation.
  
  
• Understanding Web Services specifications: Esta série de tutoriais apresenta muitos dos padrões de serviços da Web importantes, incluindo:
  • "Understanding Web Services specifications: Web Services Description Language (WSDL)" (Nicholas Chase, developerWorks, julho de 2006)
  • "Understanding Web Services specifications: WS-Security" (Nicholas Chase, developerWorks, agosto de 2006)
  • "Understanding Web Services specifications: WS-Policy" (Tyler Anderson, developerWorks, fevereiro de 2007)
  
  
• OASIS Web Services Security (WSS) TC: Esta é a organização responsável pela especificação de WS-Security e perfis de token. É possível localizar links aqui para todas as versões desses padrões.
  
  
• O W3C Web Services Policy Working Group: Esse grupo define a especificação da WS-Policy.
  
  
• OASIS Web Services Secure Exchange (WS-SX) TC: Esta organização é responsável por WS-SecurityPolicy, WS-SecureConversation e WS-Trust.
  
  
• zona de tecnologia Java do developerWorks: Encontre centenas de artigos sobre cada aspecto da programação Java.
  
  

Discutir

• Participe da comunidade My developerWorks. Entre em contato com outros usuários do developerWorks e explore os blogs, fóruns, grupos e wikis voltados para desenvolvedores.
  
  

Sobre o autor

Dennis 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.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Criptografando e Assinando sem Certificados de Clientes
• Configuração de WS-SecurityPolicy
• WS-SecureConversation sem Certificados de Clientes
• Comparando Desempenho
• Resumindo
• Download
• Recursos
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais