 | Nível: Intermediário Dennis Sosnoski, Consultant, Sosnoski Software Solutions, Inc.
07/Jul/2009 O WS-Security oferece recursos poderosos para proteger aplicativos de serviços da Web e, para muitos aplicativos, esses recursos são essenciais. Mas esses recursos têm um alto custo em termos de desempenho e gasto adicional de mensagem. Dennis
Sosnoski continua sua série da coluna sobre Serviços da Web Java observando como o uso do WS-Security ou do WS-SecureConversation afeta o desempenho do Axis2 e discute quando a alternativa mais simples (e de melhor desempenho) de conexões HTTPS protegidas é uma opção mais apropriada.
O WS-Security fornece um conjunto abrangente de recursos de segurança para aplicativos de serviço da Web, agregando a padrões de mercado estabelecidos para criptografia e assinatura e criptografia XML. É possível especificar os recursos a serem usados para um aplicativo específico com WS-Policy e WS-SecurityPolicy, permitindo que os próprios clientes do serviço configurem automaticamente para acessar o serviço. Com suporte disseminado para esses padrões em diversas plataformas e estruturas de serviços da Web, a interoperabilidade é boa (e está ficando melhor ao longo do tempo).
Apesar desses benefícios, o WS-Security também possui desvantagens. Você viu nos dois últimos artigos desta série que o WS-Security pode ser complexo para configurar e que às vezes inclui muita coisa nas mensagens que estão sendo trocadas. Portanto, quando os benefícios do WS-Security valem a pena? Neste artigo, os custos de tempo de execução do WS-Security e do WS-SecureConversation relacionados serão melhor observados (em termos de gasto adicional de processamento e de coisas incluídas), levando a uma discussão sobre como aplicar o WS-Security de maneira que faça sentido para seu aplicativo.
Observando o Desempenho
Para medir o desempenho do aplicativo em diferentes configurações, este artigo usa a abordagem de cronometrar a execução de uma sequência específica de pedidos quando o cliente e o servidor são executados em um único sistema. Essa abordagem tem algumas desvantagens — a mais significativa é combinar o gasto adicional de processamento do cliente e do servidor, impossibilitando a avaliação dos mesmos separadamente — mas oferece a vantagem de obter de forma geral resultados mais consistentes em vez de executar testes em uma rede. Também é fácil tentar os testes em seu próprio hardware e JVM, o que pode ser feito usando o código fornecido (consulte Download).
Aplicativo de Teste de Desempenho
O aplicativo usado para testes é um serviço de recuperação de dados sísmico. É baseado em um banco de dados real de mais de 93.000 terremotos que ocorreram em todo o mundo em um período de anos. Pedidos ao serviço especificam intervalos de consulta para latitude, longitude, data ou magnitude e o serviço retorna todos os terremotos correspondentes agrupados por região e em ordem de data. Todo o banco de dados é mantido na memória e indexado para processamento rápido de pedidos, de forma que praticamente todo o tempo de processamento para cada pedido seja gasto no código real do processamento de serviços da Web (incluindo o código de ligação de dados que converte para e a partir de XML).
A Lista 1 mostra um pedido de amostra para o serviço, seguido pela resposta (reformatada para se ajustar à largura da página):
Lista 1. Pedido e Resposta de Amostra
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:matchQuakes xmlns:ns1="http://ws.sosnoski.com/seismic/types">
<ns1:min-date>2001-08-08T16:31:05.752+00:00</ns1:min-date>
<ns1:max-date>2001-08-14T23:51:31.499+00:00</ns1:max-date>
<ns1:min-long>160.4685</ns1:min-long>
<ns1:max-long>178.19693</ns1:max-long>
<ns1:min-lat>-42.423557</ns1:min-lat>
<ns1:max-lat>-30.44976</ns1:max-lat>
</ns1:matchQuakes>
</soapenv:Body>
</soapenv:Envelope>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body>
<ns1:results xmlns:ns1="http://ws.sosnoski.com/seismic/types" count="9">
<ns1:result-set>
<ns1:area-name>New Zealand Region</ns1:area-name>
<ns1:regions count="0">
<ns1:region ident="rgn159" index="159">NORTH ISLAND,
NEW ZEALAND</ns1:region>
<ns1:region ident="rgn160" index="160">OFF E. COAST OF N. ISLAND,
N.Z.</ns1:region>
</ns1:regions>
<ns1:quakes count="9">
<ns1:quake time="2001-08-11T09:52:54.000+00:00" millis="1000"
latitude="-37.6499" longitude="177.74" depth="83.0" magnitude="4.4"
method="ML" region="rgn160"/>
<ns1:quake time="2001-08-11T09:52:55.000+00:00" millis="0"
latitude="-37.71" longitude="177.77" depth="70.0" magnitude="4.5"
method="ML" region="rgn160"/>
<ns1:quake time="2001-08-11T15:02:47.000+00:00" millis="5600"
latitude="-38.0429" longitude="175.632" depth="299.8" magnitude="4.6"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-12T07:42:41.000+00:00" millis="7000"
latitude="-37.97" longitude="175.97" depth="289.0" magnitude="4.3"
method="MB" region="rgn159"/>
<ns1:quake time="2001-08-12T22:37:58.000+00:00" millis="5600"
latitude="-38.3839" longitude="176.121" depth="163.2" magnitude="4.0"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-12T23:25:09.000+00:00" millis="6700"
latitude="-39.9559" longitude="176.115" depth="76.0" magnitude="4.0"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-13T05:10:07.000+00:00" millis="4300"
latitude="-37.5859" longitude="176.651" depth="189.0" magnitude="4.3"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-14T02:43:18.000+00:00" millis="2900"
latitude="-38.3699" longitude="175.902" depth="193.4" magnitude="4.5"
method="ML" region="rgn159"/>
<ns1:quake time="2001-08-14T18:02:35.000+00:00" millis="5400"
latitude="-37.8159" longitude="176.375" depth="193.3" magnitude="4.5"
method="ML" region="rgn159"/>
</ns1:quakes>
</ns1:result-set>
</ns1:results>
</soapenv:Body>
</soapenv:Envelope> |
Nos testes, o cliente gera uma série pseudo-randomizada de pedidos com os intervalos de consulta ajustados para cobrir alguma parte do conjunto total de terremotos. A mesma sequência de pedidos é gerada toda vez que o cliente é executado com os mesmos parâmetros de entrada, permitindo testes de diferentes configurações de serviços da Web. Alternando os parâmetros de entrada para o cliente (que, por sua vez, altera os intervalos de consulta usados para pedidos), é possível testar diferentes tamanhos de mensagens de resultados facilmente.
Desempenho do WS-Security
Os resultados do teste mostrados neste artigo são baseados em duas sequências de pedidos. A primeira sequência usa 1.000 pedidos, com parâmetros de consulta ajustados de forma que cada consulta corresponda somente a uma pequena parte de todo o banco de dados de terremotos (retornando somente 816 terremotos para os 1.000 pedidos). O segundo conjunto usa 100 pedidos, ajustados para corresponderem a uma parte maior do banco de dados (retornando 176.745 terremotos correspondentes para os 100 pedidos). Cada sequência de pedido foi executada diversas vezes em diferentes configurações de segurança, com apenas o melhor tempo para cada configuração mantido nos resultados.
Os testes foram executados em um sistema Mandriva 2009.1 de 64 bits Linux® com um processador Athlon X2 5400+ e 4 GB de RAM, usando uma JVM Sun Java 1.6.0_13 de 32 bits. O código do servidor foi executado no Tomcat 6.0.20, configurado para usar 1.024 MB de heap, com o código do cliente usando 512 MB de heap. O Axis2 versão 1.5 foi usado com uma compilação atual do código do Rampart. (Na época dos testes, nenhum release real do Rampart correspondente ao código do Axis2 1.5 estava disponível.) Os 1.024 MB de heap no Tomcat eram surpreendentemente necessários para executar o conjunto completo de testes (que usou um aplicativo de serviço da Web separado para cada configuração de segurança); ao testar inicialmente com 256 MB de heap, os testes do WS-Security às vezes falharam com erros estranhos sem sentido (por exemplo, "A mensagem SOAP NÃO DEVE conter uma Document Type Declaration (DTD)", sendo que nenhuma DTD estava presente) ou java.lang.OutOfMemoryError.
Os testes foram executados usando cada uma das seguintes configurações:
- plain : Sem segurança
- ssl : HTTPS usado para conexão com o servidor
- username :
UsernameToken de texto simples do WS-Security nos pedidos
- sign : Assinatura do WS-Security de corpo e cabeçalhos, com registro de data e hora
- encr : Criptografia do WS-Security do corpo
- signencr : Assinatura do WS-Security de corpo e cabeçalhos, com registro de data e hora e criptografia do corpo
Os tempos de teste reais variaram de 4 segundos para a configuração plain a 55 segundos para a configuração signencr. A Figura 1 mostra os tempos de teste relativos, normalizados para múltiplos dos tempos da configuração plain para facilitar a comparação:
Figura 1. Comparação de Tempo de Teste
Como pode ser visto na Figura 1, a criptografia de Secure Sockets Layer (SSL) — tecnicamente agora Transport Layer Security (TLS), mas referido neste artigo pela abreviação antiga por questão de familiaridade — fornece um desempenho próximo ao do caso não seguro (apesar de ser melhor no caso de mensagens maiores do que no das menores, levando aproximadamente 80 por cento mais tempo para o caso de mensagens pequenas versus 20 por cento mais tempo para as mensagens maiores). Usar o WS-Security, por outro lado, causa algumas quedas de desempenho enormes. Apenas incluir cabeçalhos UsernameToken simples nas mensagens de pedido faz com que o desempenho caia para aproximadamente o mesmo nível que SSL no caso de mensagens pequenas e fica muitas vezes mais lento do que SSL no caso de mensagens maiores. No caso da assinatura e criptografia combinadas, o tempo de teste é mais de 2.100 por cento mais longo do que no caso não seguro.
Parte desse impacto no desempenho pelo WS-Security deve-se a uma falha na implementação do manipulador do Rampart, que faz com que converta cada mensagem de pedido e resposta para o formato Document Object Model (DOM) toda vez que Rampart estiver comprometido (mesmo se nenhum processamento de segurança for ser realizado para a mensagem). Esse problema específico deve ser corrigido em tempo para que um release do Rampart 1.5 acompanhe o Axis2 1.5. Dependendo de como a correção for implementada, pode melhorar de forma significativa os tempos para o teste de UsernameToken. Mas até mesmo uma correção desse problema provavelmente não afetará os outros tempos do WS-Security.
O restante do impacto no desempenho pelo WS-Security deve-se a uma combinação de como a Assinatura XML e a Criptografia XML operam e às bibliotecas usadas para as implementações do WS-Security e esses padrões XML. É possível se lembrar de "Assinatura e Criptografia do WS-Security do Axis2" que a assinatura de mensagens XML requer uma etapa chamada canonicalização, que converte o XML em um formato canônico específico antes de um valor de assinatura ser computado. O padrão requer essa etapa, pois a decisão foi feita de preservar assinaturas mesmo após XML ser separado por um analisador e gerado novamente. Apesar de essa ser certamente uma característica útil da Assinatura XML, inclui muito gasto adicional no processamento. Parcialmente porque a canonicalização é mais facilmente implementada usando um modelo DOM, as bibliotecas de segurança XML são todas gravadas para funcionarem com representações DOM de XML. (Por isso os manipuladores do Rampart atualmente geram um DOM se estiverem comprometidos até mesmo com um serviço ou cliente, supondo que DOM será necessário de qualquer forma.) Apenas a etapa de converter dados em uma representação DOM causa grande parte do gasto adicional do WS-Security, como se pode ver nos tempos de UsernameToken. No caso das mensagens de respostas grandes, esse gasto adicional parece ser referente ao mesmo que do processamento de assinatura ou criptografia real (visto na Figura 1 comparando a barra vermelha para o caso do nome de usuário — onde a criação do DOM é o único gasto adicional principal — àqueles para os casos de assinatura e criptografia, onde o processamento real criptográfico é realizado após o DOM ser criado).
Além do problema do DOM, grande parte do gasto adicional do WS-Security é o trabalho de computação intensivo de gerar compilações e dados de criptografia. Essa parte do trabalho é necessária independentemente do método de implementação usado, portanto, há um limite sobre quanta melhoria pode ser feita nos tempos de processamento do WS-Security. Artigos futuros desta série irão comparar o desempenho de algumas outras implementações do WS-Security com Axis2/Rampart — mas a maioria delas usa as mesmas bibliotecas subjacentes, portanto, não espere ver nenhuma grande diferença.
WS-SecureConversation
O WS-SecureConversation é um padrão que baseia-se nos padrões WS-Security e WS-Trust para suportar trocas seguras envolvendo diversas mensagens. Como usa um contexto para uma troca de mensagens contínua, o WS-SecureConversation é potencialmente mais eficiente do que o WS-Security. A distribuição do Rampart inclui um módulo separado chamado rahas que permite emitir tokens de segurança necessários para o WS-SecureConversation. Também inclui um exemplo (samples/policy/sample04) de uma configuração de política usando o WS-SecureConversation, que foi a base para uma política usada com o aplicativo de teste de desempenho.
A política do WS-SecureConversation (não mostrada aqui, mas presente no download como secureconversation-policy-client.xml) inclui um elemento <sp:SecureConversationToken> que detalha o tipo de token de segurança que será usado para a troca de mensagem e fornece as opções de segurança a serem aplicadas nas mensagens de troca de token. Essas mensagens de troca de token pegam carona na troca de mensagens regular entre o cliente e o serviço, usando operações implementadas pelo módulo rahas — portanto, quando o WS-SecureConversation estiver em uso, você verá pares de mensagens de pedido/resposta ocasionais entre o cliente e o servidor, conforme mostrado na Lista 2. Essas mensagens de troca de token incluídas podem ser distinguidas das mensagens do aplicativo por seu uso de diferentes opções de segurança, conforme configurado pela política, e por seu uso dos códigos de ação especiais de pedido http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT e de resposta http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT, os quais são definidos pelo WS-SecureConversation.
Lista 2. Pedido e Resposta de Amostra
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
soapenv:mustUnderstand="1">
...
</wsse:Security>
<wsa:To
>http://localhost:8800/axis2/services/seismic-secureconversation</wsa:To>
<wsa:ReplyTo>
<wsa:Address
>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:Address>
</wsa:ReplyTo>
<wsa:MessageID>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:MessageID>
<wsa:Action>http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT</wsa:Action>
</soapenv:Header>
<soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Id-30222347">
<xenc:EncryptedData ...>
...
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope>
<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header xmlns:wsa="http://schemas.xmlsoap.org/ws/2004/08/addressing">
<wsse:Security xmlns:wsse="http://...-wss-wssecurity-secext-1.0.xsd"
soapenv:mustUnderstand="1">
...
</wsse:Security>
<wsa:To
>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</wsa:To>
<wsa:MessageID>urn:uuid:1BCDE6BE423F5FDE791246409571325</wsa:MessageID>
<wsa:Action
>http://schemas.xmlsoap.org/ws/2005/02/trust/RSTR/SCT</wsa:Action>
<wsa:RelatesTo>urn:uuid:5EA8E8F04EBA73255B1246409570148</wsa:RelatesTo>
</soapenv:Header>
<soapenv:Body xmlns:wsu="http://...-wss-wssecurity-utility-1.0.xsd"
wsu:Id="Id-5148380">
<xenc:EncryptedData ...>
...
</xenc:EncryptedData>
</soapenv:Body>
</soapenv:Envelope> |
Para comparar o desempenho com o WS-Security regular usando certificados, a configuração do WS-SecureConversation foi configurada para usar o token de sessão somente para corpos de mensagens de criptografia. A Figura 2 mostra como os tempos de teste resultantes se comparam às configurações de teste plain e encr, novamente normalizados para múltiplos dos tempos de configuração plain para facilitar a comparação:
Figura 2. Comparação do Tempo do WS-SecureConversation
Como se pode ver na Figura 2, a criptografia do WS-SecureConversation fornece uma melhora de desempenho significativa com relação ao WS-Security. Isso é verdadeiro principalmente no caso de mensagens menores, para as quais a configuração do WS-SecureConversation era quase que duas vezes mais rápida que a criptografia do WS-Security usando certificados. A vantagem do desempenho é muito menos pronunciada no caso de mensagens maiores, mas o WS-SecureConversation ainda é uns consideráveis 18 por cento mais rápido nesse caso.
Comparações de Tamanhos de Mensagens
Como visto em artigos anteriores desta série, o WS-Security pode incluir muita coisa nos cabeçalhos de mensagens SOAP. Isso que é incluído pode ter um efeito significativo no desempenho quando os dados são enviados entre o cliente e o servidor através de uma rede (diferentemente nos testes de desempenho executados para este artigo, onde o cliente e o servidor estavam em execução no mesmo sistema). A qualidade da conexão de rede entre o cliente e o servidor determina o impacto que esse tamanho incluído tem no desempenho, mas, claramente, quanto maior as mensagens, mas lentamente elas são trocadas.
A Figura 3 mostra os tamanhos reais das mensagens representativas nas diferentes etapas de teste, novamente normalizados para múltiplos dos resultados da configuração plain para facilitar a comparação:
Figura 3. Comparação do Tamanho da Mensagem
Como seria esperado ver, a configuração username agrega somente ao tamanho da mensagem de pedido, pois o UsernameToken está presente somente nas mensagens de pedido. As outras configurações de segurança sempre agregam aos tamanhos das mensagens de pedido e de resposta. O que é incluído pelo WS-Security é mais significativo para as mensagens de pedido e de resposta menores, novamente, conforme esperado. O tamanho dos cabeçalhos do WS-Security é basicamente uma constante para cada configuração, portanto, esse aumento de tamanho constante tem um efeito muito mais drástico quando o tamanho da mensagem original é pequeno. Quando a criptografia é usada, um efeito de preenchimento separado ocorre a partir da codificação base64 usada para os dados criptografados.
Quando Usar o WS-Security
Agora que você viu o efeito do WS-Security no tempo de processamento e no tamanho da mensagem, deve estar imaginando quando vale a pena.
A resposta curta é: quando a alternativa mais simples de SSL não funcionar.
No restante desta seção, será possível obter algumas diretrizes para ajudá-lo a determinar se suas necessidades podem ser cobertas por SSL ou se requerem a solução de força integral WS-Security e obter também alguns indicadores sobre como minimizar o gasto adicional envolvido quando você realmente usar o WS-Security.
Mantendo Segredos em Segurança
Preservar a confidencialidade é um dos aspectos mais importantes da segurança. O WS-Security usa a Criptografia XML para manter o conteúdo da mensagem em segredo para todos, exceto o destinatário-alvo, geralmente agregando às chaves públicas agrupadas em certificados digitais. A criptografia pode ser aplicada em toda a mensagem ou em partes selecionadas e pode-se, até mesmo, usar diversas camadas de criptografia para controlar quais informações estarão acessíveis para cada participante em uma troca de mensagens envolvendo diversos sistemas.
Um exemplo de caso de uso para o WS-Security é um sistema de compra on-line no qual o cliente conecta a um sistema comerciante para fazer um pedido, mas o pagamento (por exemplo, com cartão de crédito) precisa ser confirmado por um sistema bancário antes de o pedido ser processado.
Se o sistema comerciante tiver acesso às informações do cartão de crédito em formato não criptografado, ele cria o tipo de risco de segurança que tem sido endêmico com os sites de compras baseados em navegador: os números de cartão de crédito frequentemente acabam armazenados em bancos de dados com segurança fraca vulneráveis a hackers. Usando o WS-Security, as informações de cartão de crédito podem, em vez disso, ser enviadas em formato criptografado que possa ser decriptografado somente pelo sistema bancário que emite a confirmação de pagamento.
Mas para muitos aplicativos, o WS-Security e a Criptografia XML são exagerados quanto à preservação da confidencialidade. Se seu serviço for contatado diretamente por clientes (em vez de indiretamente, através de outros servidores) e executar todo o processamento necessário diretamente, pode-se usar apenas conexões SSL (HTTPS) para acesso para fornecer garantias de confidencialidade excelentes a um custo de desempenho muito mais baixo do que com o WS-Security. Essa abordagem funciona somente com conexões de cliente diretas, no entanto. Caso contrário, se o serviço precisar passar informações para outros serviços, volta-se à mesma situação dos Web sites de compras on-line vulneráveis, onde uma conexão segura é usada para passar suas informações de cartão de crédito ao site de compras, mas não há nenhuma garantia de que as informações serão mantidas seguras pelo servidor do site.
Mantendo Integridade de Dados
A integridade de dados é um problema semelhante ao de confidencialidade. O WS-Security usa a Assinatura XML para assegurar que os dados não foram corrompidos no trânsito, pois qualquer corrupção invalidaria a assinatura. Como com a Criptografia XML, a assinatura pode ser aplicada a toda a mensagem ou a partes selecionadas e pode-se usar diversas camadas de assinatura para garantir a integridade dos dados processados pelo participante em uma troca de mensagens envolvendo diversos sistemas.
O sistema de compras on-line hipotético também fornece um bom exemplo para integridade de dados. Usando o WS-Security, o cliente poderia assinar as instruções de pagamento a serem enviadas ao sistema bancário, evitando qualquer modificação no valor pretendido do pagamento pelo intermediário do sistema comerciante. Como o valor de pagamento é assinado pelo cliente, não precisaria ser criptografado, permitindo que o sistema comerciante confirme se o valor do pagamento está correto antes de enviá-lo ao sistema bancário.
Aqui, novamente, o WS-Security e a Assinatura XML podem ser exagerados se seu serviço for contatado diretamente pelos clientes e executar todo o processamento necessário internamente.
As conexões SSL não apenas mantêm os dados confidenciais, também evitam modificação dos dados em trânsito
— mas somente entre um único cliente e servidor. Se o servidor passar dados para outros sistemas, esses sistemas não têm qualquer garantia de que os dados não foram modificados pelo servidor.
Garantindo Autenticidade
A autenticidade é uma área na qual o WS-Security fornece recursos que SSL não pode igualar, mesmo para uma conexão direta entre cliente e servidor. Usar o WS-Security e a Assinatura XML para assinar uma mensagem fornece um documento que não apenas pode ser verificado como autêntico no momento de recebimento e processamento, mas também pode ser armazenado para propósitos de auditoria com a garantia de autenticidade intacta.
O melhor que SSL pode fazer nessa frente é requerer certificados de clientes como prova de identidade ao estabelecer a conexão entre o cliente e o servidor. Isso fornece uma garantia muito mais fraca de autenticidade do que a assinatura digital de mensagens, no entanto. Não é possível armazenar facilmente todo o fluxo de dados trocado entre o cliente e o servidor como parte de uma conexão SSL, portanto, mesmo se você verificar o certificado do cliente ao estabelecer essa conexão, não há como voltar posteriormente e provar que essa etapa foi tratada corretamente.
Retornando novamente ao exemplo do sistema de compras on-line, a assinatura do cliente em uma instrução de pagamento permitiria que essa instrução fosse mantida pelo sistema bancário e fornecida em caso de qualquer disputa posterior com relação à transação. Isso permitiria que o sistema bancário comprovasse que o pagamento foi autorizado pelo cliente e, portanto, o afastaria de qualquer responsabilidade.
Além do Básico
Além do básico de confidencialidade, integridade e autenticidade, o WS-Security fornece muitos outros recursos para requisitos de segurança especializados. UsernameToken, por exemplo, é um recurso único que fornece uma maneira padrão de comunicar a autenticação básica do usuário para um serviço. Outros recursos do WS-Security permitem que tokens de autorização Security Assertion Markup Language (SAML) e outros formatos de informações relacionadas à segurança sejam incluídos nas trocas de mensagens SOAP. Se precisar usar informações de segurança desse tipo em seus serviços da Web, provavelmente, você irá querer usar o suporte ao WS-Security para transportar as informações, pois define formatos e procedimentos padrão que provavelmente são mais robustos do que aqueles que você poderia implementar por conta própria.
Cortando o Custo do WS-Security
Se for usar o WS-Security, é possível ver nos resultados de testes deste artigo que o desempenho pode ser um problema. Antes de entrar em pânico, no entanto, pare para considerar o volume de dados para seu serviço. Cortar o desempenho de um serviço por um fator igual a 22 ao usar o WS-Security para criptografia e assinatura é uma perspectiva amedrontadora — mas se seu serviço estiver trocando apenas algumas mensagens por hora, a diferença será insignificante em termos de demandas de hardware.
Em casos em que o desempenho é uma preocupação válida, é possível ajudar a minimizar o impacto no desempenho pelo WS-Security através de uso inteligente de suas opções de segurança. Determinadas estruturas de serviços da Web tendem a gerar todas as configurações de segurança acima, com mensagens integralmente assinadas e criptografadas usando o WS-Security e enviadas através de conexões SSL.
Isso funciona bem se você realmente deseja proteção máxima e não se importa com o desempenho, mas, na maioria dos casos, faz mais sentido usar SSL (se estiver preocupado somente em proteger as informações em trânsito entre o cliente e um único servidor) ou a criptografia do WS-Security (se precisar enviar dados para diversos servidores enquanto preserva a confidencialidade ao passar pelos intermediários).
Também é possível usar o WS-SecureConversation para trocas de mensagens de longa execução entre clientes e um servidor (mesmo um acessado através de intermediários), para um ganho relativamente modesto, mas significativo, no desempenho em comparação ao WS-Security usando certificados. O WS-SecureConversation funciona muito bem em trocas de mensagens relativamente pequenas onde o gasto adicional agregado de certificados e criptografia assimétrica pode ser grande em comparação à criptografia real (simétrica) do corpo da mensagem.
Outra maneira de cortar o custo do desempenho do WS-Security é transferir o processamento de segurança para hardware especializado.
Alguns dispositivos de gateway XML fornecem processamento acelerado de criptografia e assinaturas do WS-Security. Esses dispositivos podem ser usados para tratar do processamento pesado do WS-Security enquanto se trabalha com SOAP simples em seu aplicativo. Obviamente você precisa assegurar que não seja aberto nenhum buraco em potencial na segurança ao incluir um dispositivo em seu servidor. E deve-se testar os ganhos de desempenho com o dispositivo antes da compra. Mas, pelo menos em teoria, esse tipo de acordo pode oferecer alguns ganhos de desempenho reais.
Resumindo
O custo de desempenho do WS-Security pode ser significativo e há momentos em que a criptografia ponto a ponto SSL simples pode ser uma melhor solução.
Mas para muitos tipos de aplicativos, SSL é inadequado.
Nesses casos, o WS-Security (ou seu filho,
WS-SecureConversation) é necessário e o custo do desempenho é simplesmente uma despesa necessária. Neste artigo, você leu sobre os custos do WS-Security e aprendeu algumas diretrizes para ajudá-lo a decidir se o WS-Security é apropriado para seu aplicativo.
No próximo artigo desta série, será dada mais uma olhada no WS-Security, desta vez demonstrando o uso do WS-SecurityPolicy para controle granular dos recursos do WS-Security usados por operações individuais em um aplicativo de serviço da Web. Controlar o WS-Security no nível de operação é ainda outra técnica que pode (pelo menos potencialmente) reduzir o gasto adicional do WS-Security, portanto, é uma excelente sequência para este artigo antes de a série seguir para outros tópicos.
Download | Descrição | Nome | Tamanho | Método de download |
|---|
| Source code for this article | j-jws6.zip | 1.6MB | HTTP |
|---|
Recursos Aprender
Obter produtos e tecnologias
Discutir
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. |
Avalie esta página
| |
