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. Sugiro a leitura do artigo “WS-Trust
e WS-SecureConversation“, para que você aprenda 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.
Hoje veremos como configurar o WS-SecureConversation nas três principais
pilhas de serviços da Web em software livre Apache Axis2, Metro e
Apache CXF.
Configurando o WS-SecureConversation
O cliente de uma troca de mensagem do WS-SecureConversation se conecta primeiramente a um terminal de Security Token Service (STS) para estabelecer um contexto de segurança que inclui uma chave de segredo compartilhado. A 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 destaque azul.
Listagem 1. WS-Policy para testes de desempenho de assinatura
<wsp:Policy wsu:Id="SecureConv" ...><br /> <wsp:ExactlyOne><br /> <wsp:All><br /> <wsap:UsingAddressing xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/><br /> <sp:SymmetricBinding><br /> <wsp:Policy><br /> <sp:ProtectionToken><br /> <wsp:Policy><br /> <sp:SecureConversationToken sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"><br /> <wsp:Policy><br /> <sp:RequireDerivedKeys/><br /><strong><sp:BootstrapPolicy></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:AsymmetricBinding></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:InitiatorToken></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToRecipient"></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:RequireThumbprintReference/></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:X509Token></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:InitiatorToken></strong><br /><strong> <sp:RecipientToken></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:X509Token sp:IncludeToken=".../IncludeToken/AlwaysToInitiator"></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:RequireThumbprintReference/></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:X509Token></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:RecipientToken></strong><br /><strong> <sp:AlgorithmSuite></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:TripleDesRsa15/></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:AlgorithmSuite></strong><br /><strong> <sp:Layout></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:Strict/></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:Layout></strong><br /><strong> <sp:IncludeTimestamp/></strong><br /><strong> <sp:OnlySignEntireHeadersAndBody/></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:AsymmetricBinding></strong><br /><strong> <sp:SignedParts></strong><br /><strong> <sp:Body/></strong><br /><strong> <sp:Header Name="To" Namespace="http://www.w3.org/2005/08/addressing"/></strong><br /><strong> ...</strong><br /><strong> <sp:Header Name="Action" Namespace="http://www.w3.org/2005/08/addressing"/></strong><br /><strong> </sp:SignedParts></strong><br /><strong> <sp:EncryptedParts></strong><br /><strong> <sp:Body/></strong><br /><strong> </sp:EncryptedParts></strong><br /><strong> <sp:Trust13></strong><br /><strong> <wsp:Policy></strong><br /><strong> <sp:MustSupportIssuedTokens/></strong><br /><strong> <sp:RequireClientEntropy/></strong><br /><strong> <sp:RequireServerEntropy/></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:Trust13></strong><br /><strong> </wsp:Policy></strong><br /><strong> </sp:BootstrapPolicy></strong><br /> </wsp:Policy><br /> </sp:SecureConversationToken><br /> </wsp:Policy><br /> </sp:ProtectionToken><br /> <sp:AlgorithmSuite><br /> <wsp:Policy><br /> <sp:Basic128Rsa15/><br /> </wsp:Policy><br /> </sp:AlgorithmSuite><br /> <sp:Layout><br /> <wsp:Policy><br /> <sp:Strict/><br /> </wsp:Policy><br /> </sp:Layout><br /> </wsp:Policy><br /> </sp:SymmetricBinding><br /> <sp:SignedParts><br /> <sp:Body/><br /> </sp:SignedParts><br /> </wsp:All><br /> </wsp:ExactlyOne><br /> </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.
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 ...><br /> <wsp:ExactlyOne><br /><br /><wsp:All><br /> ...<br /> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"> <br /><br /><ramp:user>clientkey</ramp:user><br /><br /><ramp:encryptionUser>serverkey</ramp:encryptionUser><br /><br /> <ramp:passwordCallbackClass>com.sosnoski.ws.seismic.adb.PWCBHandler</ramp:passwordCallbackClass><br /><br /><br /> <ramp:signatureCrypto><br /> <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin"><br /><br /> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property><br /> <ramp:property name="org.apache.ws.security.crypto.merlin.file">client.keystore</ramp:property><br /> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">nosecret</ramp:property><br /> </ramp:crypto><br /><br /> </ramp:signatureCrypto><br /><br /><br /><ramp:encryptionCrypto><br /> <ramp:crypto provider="org.apache.ws.security.components.crypto.Merlin"><br /><br /> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.type">JKS</ramp:property><br /> <ramp:property name="org.apache.ws.security.crypto.merlin.file">client.keystore</ramp:property><br /> <ramp:property name="org.apache.ws.security.crypto.merlin.keystore.password">nosecret</ramp:property><br /> </ramp:crypto><br /><br /> </ramp:encryptionCrypto><br /><br /><br /></ramp:RampartConfig><br /><br /> </wsp:All><br /><br /></wsp:ExactlyOne><br /></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 destaque ativa o WS-Addressing ao acionar o módulo addressing.
Listagem 3. Código do cliente no Axis2
<strong> Options options = client.getOptions();<br /> options.setProperty(RampartMessageData.KEY_RAMPART_POLICY, policy);<br /><strong><strong>client.engageModule("addressing");</strong></strong><br /> client.engageModule("rampart");</strong>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 destaque na versão editada na listagem 4:
Listagem 4. Acréscimos a services.xml no servidor Axis2
<strong><serviceGroup><br /> <service name="seismic-signencr"><br /> ...<br /> <module ref="rampart"/><br /><module ref="rahas"/><br /> <module ref="addressing"/>;<br /><br /> <wsp:Policy xmlns:sp=".../ws-sx/ws-securitypolicy/200702"<br /> xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"<br /> xmlns:wsu=".../oasis-200401-wss-wssecurity-utility-1.0.xsd"<br /> wsu:Id="SecureConv"><br /> <wsp:ExactlyOne><br /> <wsp:All><br /> <wsap:UsingAddressing<br /> xmlns:wsap="http://www.w3.org/2006/05/addressing/wsdl"/><br /> <sp:SymmetricBinding><br /> ...<br /> </sp:SymmetricBinding><br /> ...<br /><br /> <ramp:RampartConfig xmlns:ramp="http://ws.apache.org/rampart/policy"><br /> <ramp:user>serverkey</ramp:user><br /> <ramp:encryptionUser>clientkey</ramp:encryptionUser><br /> <ramp:passwordCallbackClass<br /> >com.sosnoski.ws.seismic.adb.PWCBHandler</ramp:passwordCallbackClass><br /><br /> <ramp:signatureCrypto><br /> ...<br /> </ramp:signatureCrypto><br /><br /> <ramp:encryptionCrypto><br /> ...<br /> </ramp:encryptionCrypto><br /><br /> </ramp:RampartConfig><br /> </wsp:All><br /> </wsp:ExactlyOne><br /> </wsp:Policy><br /><br /> <parameter name="sct-issuer-config"><br /> <sct-issuer-config><br /> <cryptoProperties><br /> <crypto provider="org.apache.ws.security.components.crypto.Merlin"><br /> <property name="org.apache.ws.security.crypto.merlin.keystore.type"<br /> >JKS</property><br /> <property name="org.apache.ws.security.crypto.merlin.file"<br /> >server.keystore</property><br /> <property name="org.apache.ws.security.crypto.merlin.keystore.password"<br /> >nosecret</property><br /> </crypto><br /> </cryptoProperties><br /> <addRequestedAttachedRef/><br /> <addRequestedUnattachedRef/><br /><br /> <!--<br /> Key computation mechanism<br /> 1 - Use Request Entropy<br /> 2 - Provide Entropy<br /> 3 - Use Own Key<br /> --><br /> <keyComputation>3</keyComputation><br /><br /> <!--<br /> proofKeyType element is valid only if the keyComputation is set to 3<br /> i.e. Use Own Key<br /><br /> Valid values are: EncryptedKey & BinarySecret<br /> --><br /> <proofKeyType>BinarySecret</proofKeyType><br /> </sct-issuer-config><br /> </parameter><br /><br /> <parameter name="token-canceler-config"><br /> <token-canceler-config/><br /> </parameter><br /><br /> </service><br /></serviceGroup></strong>O primeiro acréscimo mostrado na listagem 4 é o par de referências ao 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.
Na próxima parte do artigo, vamos continuar aprendendo a configurar e usar o WS-SecureConversation em mais dois serviços da Web Java em software livre: Metro e Apache CXF. Veremos também como lidam com os parâmetros de tempo de execução de
segurança e o uso WS-Addressing. Ao final, acompanhe ainda a comparação de desempenho de WS-SecureConversation.
*
artigo publicado originalmente em IBM developerWorks, por Dennis Sosnoski
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. Entre em contato com Dennis no endereço enquiry@sosnoski.com.







