Transferir tarefas de segurança do WebSphere Web Services para os IBM WebSphere DataPower SOA Appliances: Parte 5: Configurando um proxy do serviço da Web para interoperação com o cliente WCF .NET usando Tokens do Kerberos com ou sem conversa segura

O firmware do WebSphere DataPower SOA Appliance 3.8.0 interopera com a estrutura WCF .NET 3.5 e suporta várias ligações de sistema WCF. Este artigo descreve a interoperabilidade WCF-DataPower usando tokens do Kerberos. É a quinta parte na série "Offload WCF Web Service Security Policies to IBM WebSphere DataPower Appliance".

Krithika Prakash, Advisory Software Engineer, IBM  

Krithika é Engenheiro de software do WebSphere DataPower SOA Appliance, com um total de sete anos de experiência no setor de TI. É especializado em rede, segurança, segurança de serviços da Web e tecnologias XML/XSLT.



01/Abr/2010

Introdução

Este artigo descreve a interoperabilidade WCF-DataPower usando tokens do Kerberos. É a quinta parte na série "Offload WCF Web Service Security Policies to IBM WebSphere DataPower Appliance". Gostaria de agradecer a contribuição de Shiu F. Poon por revisar este artigo e por seus valiosos comentários.


Cenário básico

Usando a estrutura WCF .NET 3.5, precisamos configurar o cliente de serviços da web para usar autenticação de janelas e segurança de mensagens com tokens do Kerberos e para interoperar com o DataPower, que adiciona um proxy a um serviço da web. A Figura 1 descreve o Cenário Básico.

Figura 1. Cenário Básico
Cenário Básico

Requisitos

  • WebSphere DataPower 3.8.0 ou posterior
  • Windows 2003 Server com Active Directory
  • Computador Windows Client, que é parte do domínio Active Directory
  • Estrutura Microsoft .NET 3.5
  • Visual Studio 2008 (opcional, mas facilita as coisas)

Etapas de configuração

Vamos ver em detalhes as três principais áreas de configuração a seguir:

  1. Criando Entidades e Keytabs no Active Directory
  2. Configurando o Cliente WCF
  3. Configurando o Dispositivo DataPower

Criando Entidades e Keytabs no Active Directory

Configurando o Active Directory e o IIS

Se você já tiver um Active Directory e um IIS ativos e em execução na sua configuração, pule esta seção e passe à próxima seção, Configurando o Cliente WCF.

  • Instale o Active Directory (Controlador de Domínio)
    Saiba mais sobre [InstallActiveDirectory] ou [InstallActiveDirectoryDNS] para instalar e configurar o controlador de domínio na seção Recursos.
  • Instale o IIS (Servidor de aplicativos)
    Saiba mais sobre [InstallIIS] na seção Recursos. Isso o ajudará a instalar o IIS. Além disso, verifique a seção Resolução de Problemas a respeito de problemas como "O serviço hospedado no ISS apresenta falha".

Criar um SPN para representar o serviço ao qual o WebSphere DataPower adicionou um proxy no Active Directory

Para que o cliente obtenha um ticket Kerberos a fim de gerar o token do Kerberos, é necessário criar um SPN (Service Principal Name) para o destino. Será necessário acesso ao console Users and Computers do Active Directory, bem como ao utilitário "setspn.exe" (para Windows 2003, é possível obter os respectivos downloads com a Microsoft ou localizá-los no CD de ferramentas do Windows 2003).

  1. Crie um pseudousuário do AD, que será usado para mapear o SPN. Para este exemplo, crie um usuário do AD chamado "wcfservice".
  2. Crie um SPN mapeado para o usuário "wcfservice" criado acima:
    setspn –a dpbox/wcfservice wcfservice, em que "dpbox" é um prefixo arbitrário e "wcfservice" é o nome usado para representar o dispositivo WebSphere DataPower.
    OBSERVAÇÃO: O SPN é uma cadeia de caractere e é possível escolher qualquer nome ou formato. Por exemplo, o SPN pode ser "HOST/hostname:port" ou "HOST/hostname", etc.
  3. Certifique-se de que o SPN foi registrado corretamente:
    setspn -l wcfservice
    O SPN deve aparecer listado.

Gerar Keytab do Kerberos para o SPN

Para que o Kerberos funcione, será necessário mapear o SPN para o usuário e criar o keytab do Kerberos que será usado posteriormente com o WebSphere DataPower. Para fazer isso, use o utilitário "ktpass". Saiba mais sobre [InstallKTPass] na seção Recursos para instalá-lo.

Para o usuário de exemplo "wcfservice" e a região de exemplo "WPS.CSUPPORT.COM", o comando ktpass será da seguinte forma:

ktpass -out c:\temp\wcfservice.keytab -princ dpbox/wcfservice@WPS.CSUPPORT.COM -mapUser wcfservice -mapOp set -pass <passwordforuser> -crypto RC4-HMAC-NT [–ptype KRB5_NT_PRINCIPAL] [ –kvno <kvno>]

OBSERVAÇÃO:

  1. É importante especificar a opção -crypto como RC4-HMAC-NT para que isso funcione. (DES é mais fraco não pode interoperar com o WebSphere DataPower).
  2. –ptype KRB5_NT_PRINCIPAL é opcional.
  3. –kvno <kvno> só é exigido quando você desejar substituir o número de versão da chave (kvno) com um valor específico, digamos "-kvno 1". Um problema muito comum visto com o keytab gerado é o erro "kvno mismatch". Consulte a seção Resolução de Problemas a respeito de problemas relacionados e quais mensagens de erro esperar do WebSphere DataPower quando houver incompatibilidade de kvno.

Será necessário copiar o arquivo keytab "c:\temp\wcfservice.keytab" para o DataPower. Consulte a seção Configurando o Dispositivo DataPower.


Configurando o Cliente WCF

Download dos exemplos de WCF

Neste artigo, tentamos demonstrar a interoperabilidade dos exemplos de WCF e do WebSphere DataPower configurado para usar autenticação de janelas e segurança de mensagens com tokens do Kerberos. Na primeira etapa, precisamos confirmar que temos exemplos de cliente e serviço WCF que funcionam (ainda sem considerar o WebSphere DataPower). Se você já tiver um cliente WCF, pule esta seção e passe à próxima seção, Modificar o arquivo app.config.

  1. Instale os WCF de exemplo [WCFSamples]. Verifique que você não recebeu nenhum aviso ou mensagem de erro.
    Observação: O Active Directory e o IIS devem ter sido instalados conforme explicado na seção Configurando o Active Directory e o IIS.
  2. Vamos usar o projeto "WCF_SAMPLES\WCF\Basic\Binding\WS\Http" para criar a solução no Visual Studio 2008.
  3. Verifique se o serviço está em execução navegando até http://localhost/servicemodelsamples/service.svc?wsdl

Modificar o arquivo app.config

  1. Desabilite o uso dos tokens SPNEGO padrão.

Uma vez que você tem um cliente e um serviço WCF que funcionam, é possível seguir adiante e modificar o arquivo app.config, de forma que você desabilite o uso dos tokens SPNEGO padrão e habilite os tokens do Kerberos no lugar. A fim de interoperar com o DataPower, o cliente WCF deve estar usando os tokens do Kerberos para assinar e criptografar as solicitações. Isso pode ser feito definindo negotiateServiceCredential="false" no arquivo app.config

Listagem 1. Desabilitar o uso dos tokens SPNEGO padrão
<security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="false"
                            algorithmSuite="Basic128" establishSecurityContext="false" />
</security>
Listagem 2. Modificar algorithmSuite para Basic128
<security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="false"
                            algorithmSuite="Basic128" establishSecurityContext="false" />
</security>

Desabilitamos negotiateServiceCredential na etapa anterior. Isso resulta na modificação do algorithmSuite para Basic128, em vez do padrão Basic256. Isso é necessário devido ao fato de que os tickets do Kerberos são intencionalmente emitidos com chaves de 128 bits do Active Directory. Se você estiver interessado nos detalhes, consulte a seção Resolução de Problemas.

É possível desabilitar a conversa segura com o parâmetro "establishSecurityContext". Defini-la para "false" desabilita a conversa segura. Defina-a para "true" a fim de habilitá-la.

Listagem 3. Desabilitar/Habilitar a conversa segura
<security mode="Message">
    <transport clientCredentialType="Windows" proxyCredentialType="None"
                            realm="" />
    <message clientCredentialType="Windows" negotiateServiceCredential="false"
                            algorithmSuite="Basic128" establishSecurityContext="false" />
</security>

Quando a conversa segura é habilitada, o cliente WCF envia uma solicitação inicial "RequestSecurityToken", juntamente com os tokens do Kerberos. Após receber essa solicitação, o WebSphere DataPower irá validar os tokens do Kerberos e irá gerar um STC (Security Context Token) e enviá-lo ao cliente. Todas as transações posteriores entre o WebSphere DataPower e o Cliente serão assinadas/criptografas usando esse SCT.

Observe que, se você habilitar a conversa segura no cliente WCF, será necessário configurar o DataPower para tratar as solicitações iniciais da conversa segura. Consulte a seção Para tratar a Conversa Segura.

Em seguida, inclua um elemento "identity" com o nome da entidade de serviço criado acima. Nas configurações do cliente e do serviço.

Listagem 4. Desabilitar/Habilitar a conversa segura
<identity>
    <servicePrincipalName value="dpbox/wcfservice@WPS.CSUPPORT.COM"/>        
</identity>

Observe que a entidade de serviço especificada aqui deve ser a mesma especificada no comando ktpass descrito na seção Gerar Keytab do Kerberos para o SPN.

Em seguida, configure um Manipulador Frontal de Http do WebSphere DataPower para manipular todas as solicitações do cliente WCF. Modifique o app.config para o ponto do nome do host ou porta do WebSphere DataPower. Verifique se você possui o URI correto.

Além disso, antes de modificar o terminal, é possível tentar executar novamente o cliente e o serviço WCF (ainda sem o WebSphere DataPower) para certificar-se de que sua configuração de cliente/serviço WCF funciona e usa os tokens do Kerberos em vez dos tokens Spnego padrão.

Seu arquivo app.config modificado deve ter a aparência exibida na Listagem 5.

Listagem 5. App.config do Cliente WCF
<?xml version="1.0 encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <ws2007HttpBinding>
                <binding name=WS2007HttpBinding_ICalculator" closeTimeout="00:01:00"
                  openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                  bypassProxyOnLocal="false" transactionFlow="false" 
                                hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" 
                                maxArrayLength="16384"
                        maxBytesPerRead="4096" maxTableCharCount="16384"/>
                    <reliableSession ordered="true" inactivityTimeout="00:10:00" 
                                enabled="false"/>
                    <security mode="Message">
                        <transport clientCredentialType="Windows" 
                                proxyCredentialType="None" realm=""/>
                        <message clientCredentialType="Windows" 
                                negotiateServiceCredential="false" 
                                    algorithmSuite="Basic128" 
                                    establishSecurityContext="true"
                    </security>
               </binding>
           </ws2007HttpBinding>
        </bindings>
        <client>
   <!-- endpoint DNS name "datapower" must be configured within local hosts file -->
        <endpoint address="http://datapower:8009/WS2007HttpKrbSC/service.svc"
         binding="ws2007HttpBinding" bindingConfiguration="WS2007HttpBinding_ICalculator"
         contract="ICalculator" name="WS2007HttpBinding_ICalculator_DP">
             <identity>
            <servicePrincipalName value="dpbox/wcfservice@WPS.CSUPPORT.COM"/>
               </identity>
           </endpoint>
       </client>
   </system.serviceModel>
</configuration>

Configurando o WebSphere DataPower

Configurar um Proxy WS

O proxy dos serviços da Web deve ser configurado, para que cumpra as políticas necessárias para o wsHttpBinding/ws2007HttpBinding e exija que as transações sejam assinadas/criptografadas usando tokens do Kerberos. As seguintes ações devem ser concluídas:

  1. Adicionar o wsdl de serviço
  2. Anexar a Política de Segurança WS exigida
  3. Anexar o "Conjunto de Parâmetros da Política"
  4. Configurar a guia "Proxy Settings" para criptografia

Este artigo pressupõe que você esteja familiarizado com a configuração básica do proxy de serviços da Web – adição de um wsdl, configuração do manipulador frontal de http, fornecimento do URI correto e configuração do serviço de backend. Observe que a configuração do WebSphere DataPower no anexo inclui todas essas configurações para vários exemplos de Proxies WS.

1. Adicionar o wsdl de serviço

O wsdl do serviço de cálculo de exemplo (para w2007HttpBinding) pode ser obtido navegando até http://localhost/servicemodelsamples/service.svc?wsdl no serviço .NET em que você instalou os exemplos de WCF. Se você estiver planejando importar esse wsdl para o WebSphere DataPower, pode ser necessário copiar arquivos de esquema adicionais para o DataPower e também modificar o URI de importação do wsdl, como se vê a seguir:

<wsdl:import namespace = "http://Microsoft.ServiceModel.Samples" location =
"local:///CalculatorServiceDefinition.wsdl"/>

Além disso, não deixe de remover os elementos da política do arquivo wsdl. Você adicionará as políticas de modelo fornecidas pelo WebSphere DataPower como elementos de referência, conforme explicado nas seções a seguir.

Figura 2. Adicionar o wsdl de serviço
Adicionar o wsdl de serviço

Neste exemplo, o backend é um firewall XML de loopback que busca um arquivo AddResponse.xml estático. Geralmente, ele será substituído por um servidor da Web de backend.

O URI Local deve corresponder ao que estiver especificado no terminal do app.config do cliente.

2. Anexar a Política de Segurança WS exigida

O WebSphere DataPower fornece vários arquivos de modelos no diretório "store://policies/templates/dotnet". É necessário escolher o arquivo de modelo correto e o wsu:id correto dentro do arquivo e adicioná-lo ao wsdl. Vamos ver como selecionar o arquivo de modelo e o wsu:id "corretos".

Neste exemplo, o cliente WCF está configurado para usar ws2007HttpBinding com tokens do Kerberos e desabilitou a conversa segura. Observe ainda o AlgorithmSuite no app.config do arquivo de cliente. Ele é definido para Basic128. Portanto, a seguir estão os parâmetros que devemos considerar ao selecionar o arquivo de modelo no diretório 'store://policies/templates/dotnet'.

Template file: wsp-sp-1-2-ws2007HttpBinding.xml
Binding: symmetric
Token: Kerberos
AlgorithmSuite: Basic128 
Secure Conversation: No

Dessa forma, o elemento de referência da política deve ser da seguinte maneira:

<wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#symmetric-kerberos-basic128"/>.

As políticas de entrada e saída também devem ser adicionadas, como mostra a Listagem 6.

Listagem 6. Adicionar PolicyReference ao wsdl de serviço
<wsdl:import namespace = "http://Microsoft.ServiceModel.Samples" location =
"local:///CalculatorServiceDefinition.wsdl"/>
<wsdl:types/>
<wsdl:binding name = "WS2007HttpBinding_ICalculator" type = "i0:ICalculator">
    <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml
                                            #symmetric-kerberos-basic128"/>
    <soap12:binding transport = "http://schemas.xmlsoap.org/soap/http"/>
    <wsdl:operation name="Add">
        <soap12:operation soapAction =
"http://Microsoft.ServiceModel.Samples/ICalculator/Add" style = "document"/>
        <wsdl:input>
            <wsp:PolicyReference
URI="store:///policis/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#input"/>
            <soap12:bosy use = "literal"/>
        </wsdl:input>
        <wsdl:output>
            <wsp:PolicyReference
URI="store:///policies/templates/donet/wsp-sp-1-2/ws2007HttpBinding.xml#output"/>
            <soap:12body use = "literal"/>
        </wsdl:output>
    </wsdl:operation>       
</wsdl:binding>
<wsdl:service name = "CalculatorService">
    <wsdl:port name = "WS2007HttpBinding_ICalculator" binding =
"tns:WS2007HttpBinding_ICalculator">
        <soap12:address location = "http://wcfnet/ServiceModelSamples/service.svc"/>
        <wsa10:EndpointReference>
            <wsa10:Address>http://wcfnet/ServiceModuleSamples/service.svc</wsa10:Address>
            <Identity xmlns =
"http://schemas.xmlsoap.org/ws/2006/02/addressingidentitiy">
                <Spn>HOST/wcfnet</Spn>
            </Identity>
        </wsa10:EndpointReference>
    </wsdl:port>
</wsdl:service>

Além disso, certifique-se de habilitar a opção "WSDL-Embedded Policy References" na guia Policy, conforme é mostrado na figura a seguir.

Figura 3. Habilitar a opção WSDL-Embedded Policy References
Habilitar a opção WSDL-Embedded Policy References

Observe que, em vez de modificar o wsdl, é possível reter o wsdl de serviço original e anexar as referências de política na guia "Policy" do webgui, como é mostrado na Figura 4. No entanto, existe uma limitação. Você não pode usar o webgui para anexar a política ao "Message Policy Subject". Portanto, neste exemplo, além do que é mostrado na Figura 4, ainda é necessário adicionar as referências da política de entrada e de saída ao serviço wsdl:

<wsdl:input>
  <wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml
                           #input"/>   
    <soap12:body use = "literal"/>
</wsdl:input>
<wsdl:output>
  <wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml
                            #output"/>  
    <soap12:body use = "literal"/>
</wsdl:output>
Figura 4. Anexar política ao wsdl de serviço usando o WebGUI
Anexar política ao wsdl de serviço usando o WebGUI

3. Anexar o "Conjunto de Parâmetros da Política" exigido

No Conjunto de Parâmetros da Política, configure os parâmetros do Token do Kerberos mostrado na Figura 5.

Kerberos Server Principal - este será o SPN criando anteriormente em Gerar Keytab do Kerberos para o SPN. Por exemplo, dpbox/wcfservice@WPS.CSUPPORT.COM

Kerberos Client Principal – O nome da entidade de quem assinou a solicitação de mensagem recebida. Em nosso exemplo, wcfclient@WPS.CSUPPORT.COM é o nome da entidade do usuário conectado no computador cliente WCF e que chamou o programa cliente. Observe que "Kerberos Client Principal" não é de fato usado, a menos que você habilite o parâmetro "Enforce Kerberos Client Principal".

Keytab Kerberos – Este é o keytab da entidade do servidor. Se ainda não tiver sido criado, crie um "objeto keytab do Kerberos" carregando o arquivo keytab com o uso do comando ktpass. Consulte a seção Criando Entidades e Keytabs no Active Directory.

Interoperable with Microsoft: é necessário adicionar este parâmetro quando for necessário que o WebSphere DataPower interopere com qualquer uma das ligações suportadas pela Microsoft.

Observe que o domínio da política deve corresponder ao que é especificado no arquivo de modelo. Neste exemplo, é possível confirmar verificando o arquivo de modelo "store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml", em que o espaço de nomes da política de segurança é especificado para ser "xmlns:sp = http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702". Por isso, será necessário adicionar os parâmetros da política a esse espaço de nomes.

Figura 5. Adicionar o "Conjunto de Parâmetros da Política" ao wsdl de serviço
Adicionar o

4. Configurar a guia Proxy Settings para decriptografia

Quando wsHttpBinding/ws2007HttpBinding é usado, as mensagens são assinadas e criptografadas usando tokens do Kerberos. Para decriptografar a mensagem recebida, as credenciais de decriptografia devem ser especificadas na guia Proxy Settings do proxy dos serviços da Web, como mostra a Figura 6. O nome da Entidade do Servidor deve ser o mesmo especificado no comando ktpass e o keytab deve ser aquele criado com o comando ktpass descrito em Gerar Keytab Kerberos para o SPN. O nome da entidade do cliente aqui é opcional.

Figura 6. Credenciais de decriptografia na guia Proxy Settings
Credenciais de decriptografia na guia Proxy Settings

Conversa segura

Se o cliente WCF for configurado para habilitar a conversa segura (establishSecurityContext="true"), o WebSphere DataPower deve ser configurado para tratá-la. Isso envolve as seguintes etapas, além das etapas explicadas nas seções anteriores.

  1. Adicionar wsdl STS para tratar solicitações iniciais da conversa segura
  2. Anexar a Política de Segurança WS exigida ao wsdl STS
  3. Anexar o "Conjunto de Parâmetros da Política" exigido ao wsdl STS
  4. Desabilitar a validação do esquema

1. Adicionar wsdl STS para tratar solicitações iniciais da conversa segura

Para tratar as solicitações iniciais da conversa segura (RequestSecurityToken), precisamos adicionar um wsdl STS ao proxy dos serviços da web, Veja a Figura 7 a seguir. Observe o manipulador do terminal e o URI local. Deve haver correspondência com o que é configurado no wsdl de serviço.

Figura 7. Adicionar wsdl STS para tratar a conversa segura
Adicionar wsdl STS para tratar a conversa segura

2. Anexar a Política de Segurança WS exigida ao wsdl STS

O arquivo de modelo junto com o wsu:id correto também deve ser adicionado ao wsdl STS. Observe que, uma vez que a Conversa segura está habilitada, o elemento de referência da política deve ser <wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml #symmetric-kerberos-sc-basic128"/> para o wsdl STS e para o wsdl de serviço. A Listagem 7 mostra um exemplo de wsdl STS.

Listagem 7. Adicionar PolicyReference ao wsdl de serviço

Clique aqui para ver lista de códigos

Listagem 7. Adicionar PolicyReference ao wsdl de serviço

<?xml version="1.0" encoding="utf-8"?>
<wsdl:definitions targetNamespace="http://schemas.xmlsoap.org/ws/2005/02/trust"
    xmlns:tns="http://schemas.xmlsoap.org/ws/2005/02/trust"
    xmlns:sp="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512"
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns:echo="http://com/ibm/was/wassample/sei/echo/"
    xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/"
    xmlns:wsp="http://www.w3.org/2006/07/ws-policy"
    xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-security-utility-1.0.xsd">

<wsdl:types>
    <xs:schema targetNamespace="http://schemas.xmlsoap.org/ws/2005/02/trust"
blockDefault="#all" elementFormDefault="qualified">
        <xs:element name="RequestSecurityToken">
            <xs:complexType>
                <xs:sequence>
                    <xs:any namespace="##any" maxOccurs="unbounded"/>
                </xs:sequence>
                <xs:anyAttribute namespace="##any" processContents="lax"/>
            </xs:complexType>                
        </xs:element>
        <xs:element name="RequestSecurityTokenResponse">
            <xs:complexType>      
                <xs:sequence> 
                    <xs:any namespace="##any"/>        
                </xs:sequence> 
            </xs:complexType>
        </xs:element>
    </xs:schema>
</wsdl:types>

<!--Message part definitions for the bootstrap request/response.-->
<wsdl:message name ="RequestSecurityToken">
    <wsdl:part name="Body" element="tns:RequestSecurityToken"/>

<!--Endpoint/operation definition for bootstrap messages Policy
        attach here must include -->

<wsdl:portType name="Test">
    <wsdl:operation name="RequestSecurityToken">
        <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#symmetric-kerberos-sc-basic128"/>
        <wsdl:input message="tns:RequestSecurityToken"/>
        <wsdl:output message="tns:RequestSecurityTokenResponse"/>
    </wsdl:operation>
<wsdl:portType>

<wsdl:binding name="T1Binding" type="tns:Test">
    <soap12:binding style="document"
transport="http://schemas/xmlsoap.org/soap/http"/>
    <wsdl:operation name="RequestSecurityToken">
<!-- 
    <soap12:operation
soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT"/>
    <soap12:operation
soapAction="http://schemas.xmlsoap.org/ws/2005/02/trust/RST/SCT/Cancel"/>
-->
<!-- attach the application binding to the wsdl:input and wsdl:output, so
    the policy framework can figure out how to deal with other traffic, others
    than the Issue
-->
    <wsdl:input>  
        <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#input"/>
        <soap12:body use="literal"/>
    </wsdl:input>   
    <wsdl:output>
        <wsp:PolicyReference
URI="store:///policies/templates/dotnet/wsp-sp-1-2-ws2007HttpBinding.xml#output"/>
         <soap12:body use="literal"/>
    </wsdl:output>
</wsdl:operation>
</wsdl:binding>

<wsdl:service name="Test">
    <wsdl:port name="BootstrapPort" binding="tns:T1Binding">
        <soap12:address location="https://www.soaphub.org/RequestSecurityToken"/>
    </wsdl:port>
</wsdl:service>
</wsdl:definitions>

3. Anexar o "Conjunto de Parâmetros da Política" exigido ao wsdl STS

Anexe o mesmo parâmetro da política, descrito em Anexar o "Conjunto de Parâmetros da Política", ao terminal do wsdl STS, também conforme mostrado na Figura 8.

Figura 8. Anexar o Conjunto de Parâmetros da Política ao wsdl STS
Anexar o Conjunto de Parâmetros da Política ao wsdl STS

4. Desabilitar a validação do esquema

A resposta de "RequestSecurityToken" é assinada e criptografada. A validação do esquema deve ser desabilitada para as mensagens de pedido e resposta do wsdl STS e para as mensagens de resposta do wsdl de serviço, como se vê na Figura 9.

Figura 9. Desabilitar a Validação do Esquema
Desabilitar a Validação do Esquema

Diferenças entre wsHttpBinding e ws2007HttpBinding

Talvez você tenha percebido que os exemplos ao longo de todo este artigo usaram ws2007HttpBinding. E se você quiser usar wsHttpBinding? Veja as diferenças a seguir:

  1. Durante a configuração do cliente WCF, use <wsHttpBinding> (em vez de ws2007HttpBinding) no app.config. Veja um exemplo na Listagem 8.
Listagem 8. Exemplo de app.config para wsHttpBinding
<?xml version="1.0" encoding="utf-8"?>
<configuration>
    <system.serviceModel>
        <bindings>
            <wsHttpBinding>
                <binding name="WSHttpBinding_ICalculator" closeTimeout="00:01:00"
                    openTimeout="00:01:00" receiveTimeout="00:10:00" sendTimeout="00:01:00"
                    bypassProxyOnLocal="false" transactionFlow="false" 
                                hostNameComparisonMode="StrongWildcard"
                    maxBufferPoolSize="524288" maxReceivedMessageSize="65536"
                    messageEncoding="Text" textEncoding="utf-8" useDefaultWebProxy="true"
                    allowCookies="false">
                    <readerQuotas maxDepth="32" maxStringContentLength="8192" 
                                maxArrayLength="16384"
                        maxBytesPerRead="4096" maxTableCharCount="16384"/>
                    <reliableSession ordered="true" inactivityTimeout="00:10:00" 
                                enabled="false"/>
                    <security mode="Message">
                        <transport clientCredentialType="Windows" 
                                proxyCredentialType="None" realm=""/>
                        <message clientCredentialType="Windows" 
                                negotiateServiceCredential="false" 
                                    algorithmSuite="Basic128" 
                                    establishSecurityContext="true"
                    </security>
               </binding>
           </wsHttpBinding>
        </bindings>
        <client>
            <!-- endpoint DNS name "datapower" must be configured within local hosts
                    file-->
                <endpoint address="http://datapower:8007/WSHttpKrb/service.svc"
                    binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_ICalculator"
                    contract="ICalculator" name="WSHttpBinding_ICalculator_DP">
                    <identity>
                        <servicePrincipalName
                            value="dpbox/wcfservice@WPS.CSUPPORT.COM"/>
                    </identity>
                </endpoint>
        </client>
    </system.serviceModel>
</configuration>
  1. Enquanto você configura o arquivo wsdl do DataPower e anexa a Política de Segurança WS, certifique-se de selecionar o arquivo de modelo correto correspondente ao wsHttpBinding no momento em que for adicionar as referências da política. Por exemplo, deve ser <wsp:PolicyReference URI="store:///policies/templates/dotnet/wsp-sp-1-1-wsHttpBinding.xml#symmetric-kerberos-sc-basic128"/>
  2. Durante a configuração do Conjunto de Parâmetros da Política do DataPower, verifique se você atribui todos os parâmetros de política ao domínio de política correto que corresponde ao wsHttpBinding. Por exemplo, deve ser http://schemas.xmlsoap.org/ws/2005/07/securitypolicy

Se você chegou até aqui, já definiu toda a configuração necessária. Execute o programa cliente e veja-o processar a resposta do WebSphere DataPower.


Resolução de Problemas

O serviço hospedado no ISS apresenta falha

Por padrão, quando o IIS é configurado, o ASP.NET usa a versão 1.0. É necessário registrar-se na versão 2.0 usando o aspnet_regiis.exe -i em
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727

Se a etapa acima não for executada, não será possível implementar o serviço de exemplo (descrito neste artigo) no IIS.

Mensagem "Cannot parse file for Kerberos Keytab" ou "Bad checksum on Kerberos AP-REQ"

Se você estiver vendo este erro no DataPower, provavelmente você encontrou um famoso (e também "abominável") erro de incompatibilidade kvno ou um erro de incompatibilidade de algoritmo. Infelizmente, as mensagens de erro/log no WebSphere DataPower não são capazes de indicar os detalhes exatos da incompatibilidade ou se realmente se trata de um erro de incompatibilidade. Existe a possibilidade de ser um arquivo keytab corrompido.

Um erro de incompatibilidade de algoritmo pode ocorrer quando o algoritmo de criptografia usado no token AP-REQ é diferente daquele especificado no keytab. O "Bad checksum on Kerberos AP-REQ message" também pode ocorrer. Verifique se você usou RC4-HMAC-NT no comando ktpass.

Um erro de compatibilidade kvno pode acontecer quando o kvno no keytab usado pelo DataPower é diferente daquele kvno que o KDC está usando. É possível encontrar o número de versão da chave que o KDC está usando executando o comando [ldifde] no KDC:

Clique aqui para ver lista de códigos

ldifde -f c:\spn.txt -d "DC=<yourdomain>,DC=com" -l *,msDS-KeyVersionNumber -r "(serviceprincipalname=<yourspn>*)" -p subtree

Para o exemplo dado neste artigo, seria:

ldifde -f c:\spn.txt -d "DC=wps,DC=csupport,DC=com" -l *,msDS-K
eyVersionNumber -r "(serviceprincipalname=dpbox/wcfservice*)" -p subtree

Verifique agora o “msDS-KeyVersionNumber”. É o kvno que o KDC está usando para esse SPN específico.

Por outro lado, é possível localizar o kvno usado no arquivo keytab executando o comando kt_util em um computador Linux.

/usr/kerberos/sbin/ktutil:
read_kt <keytabfileName>

Se eles não corresponderem, gere o arquivo keytab novamente usando o comando ktpass com o parâmetro "–kvno" com o valor que está sendo usado pelo KDC.

Se ainda assim você receber esse erro, é possível que esteja havendo problemas devido às várias modificações no SPN ou em seu usuário. Exclua o snp (setspn –d) e o usuário. Crie um usuário a partir do zero, um SPN, um keytab usando o comando ktpass e copie-o para o DataPower. Verifique se os nomes da entidade estão consistentes e diferenciam maiúsculas de minúsculas e, além disso, o nome da região deve estar em maiúsculas.

O algorithmSuite=Basic256 não funciona

Quando você desabilita NegotiateServiceCrendential, algorithmSuite=Basic256 não funciona. O motivo (conforme o suporte da Microsoft) é o seguinte:

  1. Os tickets do Kerberos são intencionalmente emitidos com chaves de 128 bits. Portanto, não funcionarão com nenhum algoritmo 256 chaveado usado pelo conjunto de algoritmo "Basic256". Nesse caso, a solução é o "Basic128" que, por padrão, é usado pelo WCF na utilização da autenticação direta do Kerberos, ou seja, quando negotiateServiceCredentials é definido para "false".
  2. A mesma configuração funciona quando negotiateServiceCredentials=true. Isso ocorre porque com negotiateServiceCredentials=true, usamos SspiNegotiation (multi) em vez da autenticação direta do Kerberos (único). Com SspiNegotiation, o WCF gera uma chave criptográfica dimensionada de maneira adequada após negociar detalhes de segurança e verificar a compatibilidade em ambos os terminais. No entanto, tal liberdade não existe no caso do modo direto Kerberos. O cliente gera uma chave Kerberos de 128 bits que falha na extremidade de serviço.

Observando a análise no WebSphere DataPower

Se você tiver habilitado a Análise no DataPower, é possível ver as mensagens de pedido e solicitação que devem vir prontas para depuração.

Se você tiver realizado uma configuração para conversa segura, verá três pedidos mostrados na figura abaixo:

  1. Pedido para Token de Contexto de Segurança.
  2. Pedido de serviço real para adicionar dois números.
  3. Pedido para cancelar o token de Contexto de Segurança.
Figura 10. Observando a Análise
Observando a Análise

O que há de novo no 3.8.0

Esta seção lista os novos conteúdos do 3.8.0.

Parâmetro de política "Disable SSL Cipher Suite Check"

Este é o parâmetro da política que permite desabilitar a verificação do código ssl pelo proxy dos serviços da web. Isso estará pronto quando você tiver configurado um manipulador frontal de http e encontrar erros do proxy dos serviços da Web como "Execution of 'store:///dp/transport-check.xsl' aborted: Invalid SSL bulk encryption key length".

Após ativar "Disable SSL Cipher Suite check", veja a Figura 11: o proxy dos serviços da web não executará nenhuma validação no conjunto de criptografia SSL que já está negociado pelo manipulador frontal de http.

Figura 11. Parâmetro de política "Disable SSL Cipher Suite Check"
Parâmetro de política

Observe que também é possível solucionar o erro "Invalid SSL bulk encryption key length" configurando seu perfil de criptografia do manipulador frontal de http para usar o algoritmo ordenado pelo proxy dos serviços da Web. No entanto, isso significa que você estará restringindo diversos clientes que não suportam esse algoritmo no handshake SSL.

Parâmetro de política "Enforce Kerberos Client Principal"

O parâmetro "Kerberos client principal" de fato não é usado até que o parâmetro "Enforce Kerberos Client Principal" seja habilitado. Uma vez habilitado (consulte a Figura 12), verifique as ações geradas pela política de segurança e compare o valor de "Kerberos client principal" com o do assinante da mensagem de pedido recebida. Se os valores não corresponderem, a mensagem será rejeitada.

Figura 12. Parâmetro de política "Enforce Kerberos Client Principal"
Parâmetro de política

Ligações WCF e tokens suportados

Suportamos as ligações a seguir e os arquivos de exemplo anexos contêm o proxy do serviço da Web configurado para cada uma dessas ligações, conforme mostrado na Figura 13.

  • BasicHttpBinding - habilitado para SSL e habilitado para SSL com certificado de cliente obrigatório.
  • wsHttpBinding/ ws2007HttpBinding – Tokens do Kerberos e tokens X509 com e sem conversa segura.
  • wsFederationBinding e ws2007Federation Binding – Tokens SAML1 e SAML2.
Figura 13. Proxy dos Serviços da Web para cada ligação suportada
Proxy dos Serviços da Web para cada ligação suportada

Os arquivos de modelo em store://policies/templates/dotnet e a convenção de nomenclatura foram adicionados ao diretório store://policies/templates/dotnet conforme mostrado na Figura 14.

Figura 14. Arquivos de modelo
Arquivos de modelo

Cada um desses arquivos de modelo contém vários wsu:ids. Confira os recursos para saber mais sobre como anexar a Política de Segurança WS exigida e sobre como selecionar o arquivo de modelo e o wsu:id incluído corretos com base na ligação e no token usados na configuração do cliente WCF.

A Figura 15 mostra alguns arquivos de modelo de exemplo juntamente com o wsu:id definido neles. Por exemplo, como é possível ver, os arquivos de modelo são nomeados como wsp-sp-<version>-<BindingSupported>.xml.

Os wsu:ids dentro de cada arquivo de modelo também seguem uma convenção de nomenclatura. Por exemplo, o wsp-sp-1-2-ws2007HttpBinding.xml tem a convenção <binding>-<token>-<is_sc_enabled>-<algorithmSuite>

Figura 15. Arquivos de modelo e os wsu:ids incluídos
Arquivos de modelo e os wsu:ids incluídos

Recursos

Aprender

Obter produtos e tecnologias

Discutir

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=WebSphere
ArticleID=479720
ArticleTitle=Transferir tarefas de segurança do WebSphere Web Services para os IBM WebSphere DataPower SOA Appliances: Parte 5: Configurando um proxy do serviço da Web para interoperação com o cliente WCF .NET usando Tokens do Kerberos com ou sem conversa segura
publish-date=04012010