Configurando um Servidor Backend Protegido por Kerberos do WebSphere DataPower, Parte 1: Usando a Interface Gráfica com o Usuário da Web do DataPower

Esta primeira parte de uma série de dois artigos desmistifica o trabalho necessário para realizar uma configuração do WebSphere® DataPower que usa um servidor backend protegido por Kerberos. Este primeiro artigo descreve como criar essas configurações de maneira estática usando a Interface Gráfica com o Usuário da Web do DataPower. A parte 2 descreverá como objetos de folha de estilo customizados do DataPower são usados para configurar um gateway para um servidor backend Kerberos de maneira mais dinâmica.

Michael McMahon, Advisory Software Engineer, IBM

Photo of Michael McMahonMichael McMahon é Advisory Software Engineer da IBM e trabalha no Research Triangle Park, NC. Ele trabalhou em diversas equipes de desenvolvimento e projetos e atualmente trabalha na organização de suporte ao IBM DataPower e IBM PureApplication System.



Bill Barrus, Senior Software Engineer, Certified IT Specialist, IBM

Photo of Bill BarrusBill Barrus é Senior Software Engineer no IBM Software Group. Ele iniciou sua carreira na IBM realizando estudos de compensação de design mecânico para o programa de atualização aviônica do F-14 da Marinha dos EUA. Contribuiu para desafios de oportunidades de negócios emergentes em suporte a CATIA Engineering Analysis, Lotus Workplace Client Technology e WebSphere Voice Server. Ele foi líder da equipe mundial de suporte do WebSphere DataPower para Parceiros de Negócios IBM e se mudou para liderar a equipe do DataPower Security de suporte IBM SWG L2. Agora, é líder da equipe de suporte técnico para a nova oferta inovadora de computação em nuvem - IBM PureApplication System.



Lisa Rich, Advisory Software Engineer, IBM

Photo of Lisa RichLisa Rich é Advisory Software Engineer no IBM Software Group. Ela trabalha como líder de suporte técnico para WebSphere DataPower SOA Appliances, especializada em DataPower Security. Antes de trabalhar com o DataPower, ela foi especialista em suporte IBM SWG L2 e L3 para WebSphere Application Server, WebSphere Studio Enterprise Developer e EGL e CICSPlex System Manager. Lisa também faz parte da equipe de suporte técnico para IBM PureApplication System e IBM Workload Deployer.



10/Ago/2012

Introdução

Como membros do grupo de suporte do DataPower, frequentemente trabalhamos com clientes que têm a necessidade de conectar seus aplicativos clientes a servidores backend protegidos com autenticação do Kerberos. Inevitavelmente, um grande número desses clientes têm dúvidas com relação a como configurar um gateway ou proxy para suporte a esse tipo de solução cliente e servidor. Kerberos pode ser uma tecnologia confusa e complicada de configurar pela primeira vez, o que provavelmente explica a frequência das perguntas relacionadas a esse tópico.


Solução Kerberos

Há muitos artigos que fornecem excelentes visões gerais sobre Kerberos e descrevem os vários componentes e interações que ocorrem como parte do modelo de segurança Kerberos (consulte a seção Recursos deste artigo). Supomos que o leitor já tenha um nível de conhecimento básico sobre segurança Kerberos. Daremos ênfase às atividades relacionadas a Kerberos diretamente necessárias para configuração do DataPower. Ao disponibilizar estes artigos, esperamos ajudar a evitar atrasos e confusão ao tentar determinar como projetar e implementar soluções relacionadas a Kerberos no DataPower.

Cenário da solução

O cenário com o qual vamos trabalhar neste primeiro artigo envolve um cliente que tem um conjunto de clientes que para conectar a um aplicativo da web no servidor backend do cliente. Esse aplicativo da web é protegido por autenticação do Kerberos. Os clientes de entrada, no entanto, não são protegidos nem autenticados pelo Kerberos. Em nosso exemplo, vamos supor que os clientes sejam autenticados por autenticação básica e um servidor do Lightweight Directory Access Protocol (LDAP), mas pode ser uma entre diversas outras formas de autenticação (Observação: Alguma exposição a LDAP é relevante, pois LDAP é geralmente usado em juntamente com Kerberos.) Apesar de geralmente usarmos SSL quando usamos autenticação básica, não vamos configurar isso em nosso exemplo para manter as coisas simples.

Para permitir que esses clientes não Kerberos se comuniquem e acessem nosso aplicativo da web protegido por Kerberos, configure um Multi-Protocol Gateway no DataPower. Esse gateway é definido para aceitar solicitações de clientes de entrada como solicitações GET HTTP, autenticar e autorizar os clientes com base em suas credenciais de entrada e, em seguida, envie a solicitação do cliente ao servidor backend usando um token Kerberos para autenticação com o servidor backend. A resposta retornada do servidor backend será então passada de volta do DataPower para o cliente solicitante. Consulte a Figura 1.

Figura 1. Diagrama de visão geral do cenário da solução
Diagrama de visão geral do cenário da solução

Interação do Kerberos

Neste cenário de exemplo, estamos usando o WebSphere Application Server (doravante chamado de Application Server) como nosso servidor backend para hospedar nosso aplicativo da web. O aplicativo da web será o aplicativo "snoop" de amostra que é enviado com o Application Server. Este Application Server é configurado para suportar autenticação do Kerberos de forma que o aplicativo web não possa ser acessado sem um ticket de serviço Kerberos apropriado. Como parte da autenticação do Kerberos, o Application Server tem acesso a um arquivo keytab do Kerberos que contém um Service Principal Name (SPN) e uma chave privada correspondente. Acesso a esse arquivo keytab permite que o Application Server processe solicitações do cliente de entrada que foram autenticadas pelo Key Distribution Center (KDC) e receberam um ticket de serviço Kerberos para permitir que se comuniquem com o aplicativo da web.

Para evitar qualquer confusão, um aspecto importante dessa interação entre o DataPower e o servidor backend é que todas as solicitações do cliente ao Application Server serão enviadas ao DataPower sob um único ID do usuário autenticado do Kerberos. Todas as solicitações de entrada para o DataPower são autenticadas e autorizadas primeiramente por suas credenciais do LDAP. Se um usuário passar esse estágio de autenticação ou autorização, ele será considerado usuário legítimo para acessar o aplicativo da web. Neste estágio, se houver uma necessidade, determinados usuários podem ser removidos por filtro de acesso ao aplicativo da web. Caso contrário, é perfeitamente aceitável enviar todas as solicitações ao aplicativo da web sob um único ID do usuário do Kerberos.

Se nosso aplicativo da web fosse mais sofisticado e realmente precisasse do ID do usuário real do cliente, então, uma opção seria passar esse ID do usuário ao aplicativo da web como parte de uma mensagem SOAP. Outra opção será discutida no próximo artigo que faz parte desta série. Por enquanto, neste artigo, todas as solicitações do cliente são enviadas ao aplicativo da web protegido pelo Kerberos usando um único ID do usuário do Kerberos mapeado.


Implementando a solução no DataPower

Esta seção ilustra quais artefatos do Kerberos são necessários para configurar a configuração desejada e quais comandos são necessários para gerar esses artefatos. Não vamos entrar em detalhes sobre a configuração relacionada ao Kerberos que é necessária no Application Server para proteger o aplicativo da web, além de mencionar rapidamente algumas etapas e artefatos de configuração gerais. Para obter informações adicionais, consulte IBM Redbook: Implementing Kerberos in a WebSphere Application Server environment.

Criar uma conta de usuário do Kerberos

Para criar um SPN para servir como seu ID do usuário do cliente Kerberos do DataPower, crie um ID do usuário no Active Directory (AD). O console Users and Computers do Active Diectory será usado, executando na máquina do Domain Controller, e criará o ID do usuário a seguir: a dpkerbclient.

  1. Para configurar esse ID do usuário no console Users do AD, clique com o botão direito do mouse na pasta Users e escolha New > User. Insira dpkerbclient no campo "Full name" e no campo "User logon name". Clique no botão Next , conforme mostrado na Figura 2.
    Figura 2. Novo usuário do AD
    Novo usuário do AD
  2. Insira uma senha para essa conta e desmarque a caixa de seleção "User must change password at next logon" e marque as caixas de seleção "User cannot change password" e "Password never expires", conforme mostrado na Figura 3. Clique no botão Next .
    Figura 3. Novas opções do Usuário do AD
    Novas opções do Usuário do AD
  3. Clique no botão Finish para concluir a criação desta nova conta do usuário.

Criar um SPN de cliente

Em seguida, use o utilitário "setspn.exe" para criar um SPN para associar a essa nova conta de cliente.

  1. Abra uma janela de comando DOS na máquina do Domain Controller e emita o comando a seguir:
    setspn -a HTTP/dpkerbclient.csupport.com dpkerbclient

    Observação: "CSUPPORT.COM" é a região do AD para nosso domínio do AD. Substitua-o por seu valor de região apropriado.

    Isso cria um SPN chamado "HTTP/dpkerbclient.csupport.com" e associa esse SPN a um ID do usuário "dpkerbclient". A parte "HTTP" desse SPN é opcional, mas geralmente é um prefixo usado. Observe que o SPN é usado pelo DataPower para identificar como localizar uma chave a partir de um arquivo keytab especial (o arquivo keytab é explicado imediatamente abaixo). Também é importante observar que esse SPN faz distinção entre maiúsculas e minúsculas quando usado pelo DataPower, portanto, é necessário ser consistente com o contexto de distinção entre maiúsculas e minúsculas ao fazer referência a esse SPN. Consulte a Figura 4.

    Figura 4. Comando setspn e saída
    Comando setspn e saída

Criar o arquivo keytab do cliente

Agora que você tem um ID do usuário e um SPN para acessar o aplicativo da web, configurare o arquivo keytab do Kerberos para a configuração do Kerberos do DataPower. Como o nome sugere, o arquivo keytab contém uma tabela de chaves. Cada entrada de chave tem uma chave privada e um Service Principal Name (SPN) associado a essa chave privada. É claro que há outras informações no arquivo keytab, mas esses dois itens são os principais atributos nos quais estamos interessados. O arquivo keytab contém somente uma entrada de chave. Essa é a chave e o SPN para o ID do usuário para os quais todas as solicitações do cliente serão mapeadas pelo DataPower ao chamar o aplicativo da web.

Enquanto ainda estiver no Domain Controller, será usado um utilitário baseado no S.O. Windows® , "ktpass.exe", para criar nosso arquivo keytab. O arquivo keytab é carregado posteriormente no DataPower ao configurar o objeto de segurança pós-processamento.

  1. Emita o comando a seguir para gerar o arquivo keytab.
    ktpass -out c:\temp\dpkerbclient.keytab -princ
    HTTP/dpkerbclient.csupport.com@CSUPPORT.COM -mapUser dpkerbclient
    -mapOp set -pass * -crypto RC4-HMAC-NT
  2. Será solicitada a inserção da senha para esse ID do usuário após a tecla Enter ser pressionada. Também pode haver uma mensagem de aviso que indique que o pType e o tipo da conta não correspondem. Ignore essa mensagem. Consulte a Figura 5.
    Figura 5. Comando KTPASS e saída
    Comando KTPASS e saída

Observação: "CSUPPORT.COM" é a região do AD para nosso domínio do AD. Substitua-o por seu valor de região apropriado.

Arquivo keytab do Kerberos – aplicativo do servidor

No WebSphere Application Server, no qual o aplicativo snoop será hospedado, o administrador já configurou um ID do usuário e um SPN para serem usados como o SPN do servidor. O administrador também cria um arquivo keytab para essa conta do SPN do servidor. Esse arquivo keytab foi transferido por upload para o Application Server para decriptografar quaisquer tickets de serviço enviados a ele.

Observação: Clientes enviam um ticket de serviço a esse Application Server. Esse ticket de serviço tem informações criptografadas que somente o servidor associado a esse SPN pode decriptografar e ler (por isso o Application Server precisa de acesso ao arquivo keytab para o SPN do servidor). Isso assegura que as solicitações do cliente sejam consumidas pelo destino correto.

Apesar de supormos que esse trabalho já tenha sido concluído por um administrador, é importante saber o que esse SPN do servidor é, caso precise ajudar o administrador do Application Server na verificação de se a configuração do Kerberos está correta quando o DataPower se comunica com o servidor backend.

Como ainda está trabalhando na máquina do Domain Controller, também será emitido um comando setspn para listar e verificar o SPN do servidor associado ao servidor de aplicativos da web.

Supomos que esse SPN (HTTP/oc4102831681.csupport.com em nosso exemplo) tenha sido configurado anteriormente pelo administrador do WebSphere Application Server e pelo administrador do KDC. É necessário descobrir qual nome de conta do ID do usuário está associado ao SPN do servidor. O administrador do KDC pode fornecer essa informação. Quando tiver essa informação, emita um comando para verificar o SPN do servidor da seguinte forma:

setspn -l <ID do usuário associado ao SPN do aplicativo do servidor>

Você verá a saída a seguir a partir desse comando. Em nosso exemplo, o nome da conta para o SPN do servidor, HTTP/oc4102831681.csupport.com, é "waskerb".

Registered ServicePrincipalNames for CN=waskerb,CN=Users,DC=csupport,DC=com:
  HTTP/oc4102831681.csupport.com

Essa verificação do SPN do servidor elimina a necessidade de verificar isso posteriormente se forem encontrados problemas.


Atividades relacionadas ao DataPower

Agora que os artefatos periféricos do Kerberos foram criado, é possível iniciar o trabalho com o DataPower para criar uma configuração de Multi-Protocol Gateway (MPG) que permita que seus clientes façam solicitação ao aplicativo da web de backend protegido por Kerberos (o aplicativo snoop, neste caso). Conforme mencionado no início deste artigo, esses clientes estão entrando no DataPower como solicitações GET HTTP, protegidas por autenticação básica O DataPower aceita essas solicitações, autentica o LDAP do usuário e, em seguida, chama o aplicativo snoop de backend usando o ticket de serviço do Kerberos para autenticar com o servidor backend. A resposta do aplicativo snoop é passada de volta ao cliente.

Criar o Multi-Protocol Gateway

  1. Efetue login no console do DataPower, no domínio "default", e crie um novo domínio de usuário chamado kerbDemo.
  2. Alterne para esse novo domínio kerbDemo e clique no ícone do Multi-Protocol Gateway (MPG).
  3. No painel MPG, clique no botão Add e crie uma nova configuração do MPG chamada "kerbDemoMPG" digitando isso no campo "Multi-Protocol Gateway Name". Deixe o campo "Type" configurado para static-backend.

Definir as configurações de front side

Defina um Front Side Handler para aceitar solicitações GET HTTP na porta "50000" (essa é uma porta opcional que selecionamos para solicitações recebidas) e ignorar todas as solicitações, exceto aquelas alvo do aplicativo "snoop".

  1. Clique no botão "+" e, em seguida, selecione HTTP Front Side Handler na lista de combinação na seção "Front Side Protocol" no lado inferior direito do painel MPG, conforme mostrado na Figura 6.
    Figura 6. Selecionando tipo do Front Side Protocol Handler
    Selecionando tipo do Front Side Protocol Handler
  2. No painel "Configure HTTP Front Side Handler" resultante, digite kerbDemoFSH no campo "Name", digite 50000 para o campo "Port Number" e selecione a caixa de seleção "GET method" abaixo, conforme mostrado na Figura 7. Deixe todos os outros campos como estão e clique no botão Apply .
    Figura 7. Configurações do Front Side Handler
    Configurações do Front Side Handler
  3. Por fim, sob a subseção "Request Type", da seção "Front side settings", clique no botão de opções Non-XML já que seus clientes não estarão enviando SOAP ou XML ao DataPower. Deixe todos os outros campos ou atributos configurados para seus padrões.

Definir as configurações de back side

  1. Para as configurações de back side, insira a URL necessária para acessar o aplicativo snoop do WebSphere Application Server. Em nosso caso, http://9.42.90.238:11000/snoop.
  2. Na subseção "Response Type" da seção "Back side settings", clique no botão de opções Non-XML já que o aplicativo snoop simplesmente envia de volta uma resposta no formato HTML. Deixe todos os outros campos ou atributos configurados para seus padrões.

    Consulte a Figura 8 para as configurações finais de Back side e de Front side.

    Figura 8. Configurações de Back side e Front side
    Configurações de Back side e Front side

Definir a política do Multi-Protocol Gateway

Nesta próxima seção, você irá definir a política do MPG para autenticar seu cliente de entrada e incluir um token do Kerberos para autenticar no servidor backend.

  1. Clique no sinal de "+" na seção "Multi-Protocol Gateway Policy" da configuração de kerbDemoMPG para criar uma nova política do MPG para esta configuração.
  2. No painel "Configure Multi-Protocol Gateway Style Policy", insira kerbDemoMPGPolicy no campo "Policy Name".
  3. Na seção Rule, selecione Client to Server para a "Rule Direction". Em seguida, clique no botão New Rule .
  4. Clique duas vezes na ação Match (o losango com um sinal de igual no meio) e crie uma "Matching Rule" que corresponda a todas as solicitações do cliente de entrada direcionadas ao aplicativo snoop.
  5. Clique no sinal de "+" ao lado da caixa de combinação "Matching Rule".
  6. No painel "Configure Matching Rule" resultante, enquanto estiver na guia Main, insira kerbDemoSnoopMatch para o campo Name, conforme mostrado na Figura 9.
    Figura 9. Configura o nome da regra de correspondência
    Configura o nome da regra de correspondência
  7. Clique na guia Matching Rule do painel "Configure Matching Rule". Clique no botão Add para criar uma nova regra de correspondência. Deixe "Matching Type" configurado para URL e insira /snoop para o valor de "URL Match", conforme mostrado na Figura 10.
    Figura 10. Criar regra de correspondência
    Criar regra de correspondência
  8. Clique em Apply para salvar essas mudanças. Clique em Apply novamente no painel "Configure Matching Rule". Clique em Done no painel "Configure a Match Action" para atualizar essa nova regra de correspondência. Consulte a Figura 11.
    Figura 11. Configura ação correspondente
    Configura ação correspondente

Definir uma ação AAA

A ação AAA será definida em seguida como parte desta MPG Policy Rule. Este é o conjunto de etapas de configuração mais interessante, pois envolve diretamente artefatos do Kerberos gerados anteriormente.

  1. Na seção "Create rule:" do painel "Configure Multi-Protocol Gateway Style Policy", clique no ícone de AAA e arraste-o para a linha de regra, conforme mostrado na Figura 12.
    Figura 12. Arrastar AAA para a linha de regra
    Arrastar AAA para a linha de regra
  2. Clique duas vezes no ícone de AAA na nova posição para configurar as ações AAA. No painel "Configure AAA Action" resultante, primeiro, altere a seleção "Input" de (auto) para INPUT. Em seguida, altera o valor de "Output" de (auto) para OUTPUT, conforme mostrado na Figura 13.
    Figura 13. Configurações de Input e Output
    Configurações de Input e Output
  3. Clique no "+" à esquerda da caixa de combinação "AAA policy" para criar um novo objeto AAA Policy, conforme mostrado na Figura 14.
    Figura 14. Botão Add da AAA Policy
    Botão Add da AAA Policy
  4. No painel "Configure an Access Control Policy", insira kerbDemoAAAPolicy e clique no botão Create .
  5. No próximo painel, selecione a caixa de seleção HTTP Authentication Header na seção "Define how to extract a user's identity ..." . Clique no botão Next .
  6. Na seção "Define how to authenticate the user" do próximo painel, selecione a caixa de seleção Bind to Specified LDAP Server , conforme mostrado na Figura 15.
    Figura 15. Seleção Bind to Specified LDAP Server
    Seleção Bind to Specified LDAP Server
  7. Campos de configuração adicionais relacionados a LDAP são incluídos no painel. Preencha esses valores conforme mostrado abaixo:

    LDAP Load Balancer Group:<grupo de balanceador de carga de servidores do LDAP; o padrão é "none">

    Host:<endereço IP ou nome do host do servidor do LDAP>

    Port:<porta do LDAP; o valor padrão é "389">

    SSL Proxy Profile:<nome do perfil proxy SSL; o padrão é "none">

    LDAP Bind DN:<nome distinto (DN) da ligação que tem permissão para pesquisar o diretório do LDAP>

    LDAP Bind Password: <senha do DN da ligação>

    LDAP Search Attribute:<o padrão é "dn">

    LDAP Version:<o padrão é "v2">

    LDAP Search for DN<o padrão é "off">

    LDAP Prefix:<Cadeia de caracteres anexada à frente do nome de usuário para formar um DN para procurar, o padrão é "cn=">

    LDAP Suffix:<o padrão é um campo em branco>

    Use Auxiliary LDAP Attributes:<o padrão é none>

  8. Quando esses valores forem preenchidos de forma apropriada para corresponderem a ser ambiente do LDAP, clique no botão Next , conforme mostrado na Figura 16.

    Observações:

    • As informações necessárias para esses campos de configuração do LDAP são diferentes para cada cliente, dependendo do ambiente específico do LDAP de cada cliente. Neste artigo, tentamos usar valores padrão para tornar esta configuração demo o mais fácil possível. Alguns dos campos usados neste exemplo não são obrigatórios quando se estiver lidando com atributos de nome de usuário e senha de autenticação básica de entrada. Por exemplo, em nossa configuração do LDAP de AAA, atributos como "LDAP Bind DN" e "LDAP Bind Password" não são necessários e podem ser deixados vazios, pois se aplicam somente quando se estiver lidando com UsernameTokens de WS-Security.
    • Em nosso cenário de demo, o nome de usuário e a senha recebidos por meio do cabeçalho de autenticação básica serão usados, em vez disso, para se conectar ao LDAP e autenticar o usuário. Se seus clientes estivessem usando mensagens SOAP e elemento de WS-Security, então valores de atributos do LDAP diferentes poderiam ser necessários. A mensagem principal aqui é que esta é uma configuração simplificada. Diferentes ambientes podem requerer valores significativamente diferentes. É aconselhável que você trabalhe com seu administrador do LDAP ao configurar para seu ambiente do LDAP específico.
    Figura 16. Configurações do servidor do LDAP
    Configurações do servidor do LDAP
  9. Clique no botão Next . Na seção "Define how to extract the resources" do próximo painel, clique na caixa de seleção URL Sent to Back End conforme mostrado na Figura 17 e clique no botão Next .
    Figura 17. Defina como extrair os recursos
    Defina como extrair os recursos
  10. Na seção "Define how to authorize a request" do próximo painel, deixe a seleção padrão de botão de opções configurada para a opção Allow Any Authenticated Client , conforme mostrado na Figura 18. Isso indica que qualquer cliente que seja autenticado com sucesso estará autorizado a acessar o servidor backend. Clique no botão Next .
    Figura 18. Definir como autorizar uma solicitação
    Definir como autorizar uma solicitação

    No painel final de nossa AAA Access Control Policy, serão configurados os principais do cliente e servidor Kerberos.

  11. Na seção "Choose any post processing" desse painel, selecione o botão de opções Generate a Kerberos SPNEGO token . Isso força a inclusão no painel de campos de entrada adicionais relacionados ao Kerberos. Preencha esses valores conforme mostrado abaixo:

    Kerberos Client Principal:HTTP/dpkerbclient.csupport.com@CSUPPORT.COM

    Kerberos Client Keytab:<fazer upload do arquivo keytab do cliente gerado anteriormente no Domain Controller>

    Kerberos Server Principal: <SPN do servidor> (HTTP/oc4102831681.csupport.com@CSUPPORT.COM em nosso exemplo)

    Observação: "CSUPPORT.COM" é a região do AD para nosso domínio do AD. Substitua-o por seu valor de região apropriado, como HTTP/dpkerbclient.test.com@TEST.COM .

  12. Ao fazer upload do arquivo keytab, certifique-se de selecionar também o botão de opções Generate GSS-API Checksum in AP-REQ no painel de upload de arquivo, conforme mostrado na Figura 19. Caso contrário, o WebSphere Application Server pode rejeitar o token se não contiver uma soma de verificação para verificar se o token não foi modificado.
    Figura 19. Ativar a geração da soma de verificação
    Ativar a geração da soma de verificação
  13. Clique no botão Commit para enviar e aplicar essa configuração, conforme mostrado na Figura 20.
    Figura 20. Valores de configuração do Kerberos
    Valores de configuração do Kerberos

    Observações:

    • O nome do Kerberos Client Principal é usado para consultar e identificar a entrada de chave no arquivo Kerberos Client Keytab. Apesar de haver somente uma entrada SPN e Key no arquivo keytab do cliente, o principal do cliente especificado nesse campo é usado para corresponder e extrair essa entrada do arquivo keytab do cliente. A entrada de keytab do cliente, com a chave secreta, é necessária porque o DataPower faz uma solicitação ao servidor do KDC para obter Ticket Granting Ticket (TGT) para esse cliente. O TGT resultante, enviado de volta ao KDC, contém informações inseridas pelo KDC que podem ser decriptografadas somente com a chave do cliente (o KDC sabe qual é a chave do cliente).
    • Assim que o DataPower recebe o TGT e decriptografa uma chave de sessão a partir do TGT (usando a chave secreta do keytab do cliente), ele usa o TGT para solicitar um ticket de serviço do KDC para permitir que se comunique com o aplicativo snoop. O Kerberos Server Principal é passado ao KDC para indicar para qual serviço era o ticket de serviço. Após o DataPower receber esse ticket de serviço, ele o armazena em cache e, em seguida, usa o mesmo para criar tokens de serviço para solicitações realizadas ao aplicativo snoop (token enviado no cabeçalho de HTTP). O aplicativo snoop é configurado para autenticação do Kerberos e pode decriptografar o ticket de serviço, pois foi criptografado no KDC usando a chave secreta para o Server Principal especificado, e validar a identidade do usuário.
  14. Clique no botão Done no painel "Configure an Access Control Policy", clique em Done no painel "Configure AAA Action" e, em seguida, clique no botão Apply Policy no painel "Configure Multi-Protocol Gateway Style Policy". Em seguida, clique no link Close Window no painel "Configure Multi-Protocol Gateway Style Policy" (seção superior à direita do painel) para fechar esse painel e retornar ao painel do console principal do DataPower, conforme mostrado na Figura 21.
    Figura 21. Aplicando e fechando o MPG Style Policy
    Aplicando e fechando o MPG Style Policy
  15. No painel "Configure Multi-Protocol Gateway", clique no botão Apply para confirmar essas mudanças e, em seguida, salve a configuração, conforme mostrado na Figura 22. Agora você está quase pronto para testar a nova configuração.
    Figura 22. Aplicar mudanças na configuração atualizada para o MPG
    Aplicar mudanças na configuração atualizada para o MPG

Configurando o servidor do KDC do Kerberos

Antes de testar, é necessário configurar um servidor do KDC com o qual o DataPower irá se comunicar.

  1. No lado esquerdo do painel, expanda a pasta Objects e, em seguida, expanda a pasta Crypto Configuration . Clique no objeto Kerberos KDC Server , conforme mostrado na Figura 23.
    Figura 23. Kerberos KDC Server sob Crypto Configuration
    Kerberos KDC Server sob Crypto Configuration
  2. No painel "Configure Kerberos KDC Server", clique no botão Add para incluir uma nova entrada de servidor do KDC. Insira um nome para seu servidor do KDC (pode ser qualquer coisa significativa para você) e, em seguida, insira o nome da região no campo "Kerberos realm name" e o nome do host ou o endereço IP do servidor do KDC no campo "Kerberos KDC Server". É possível clicar no botão Ping Remote para assegurar que seja possível fazer contato com o servidor do KDC.

    Observação: O nome da região do Kerberos deve corresponder ao nome da região usado nos valores de SPN do cliente e do servidor definidos a anteriormente em sua ação AAA Post Processing, como CSUPPORT.COM. A distinção entre maiúsculas e minúsculas também é importante.

  3. Para evitar possíveis erros relacionados a tamanhos de tokens do Kerberos, ative o botão de opções "Use TCP". O campo "Server Port Number" geralmente permanece com o valor padrão (88). Clique no botão Apply para criar esse novo objeto KDC Server, conforme mostrado na Figura 24. Por fim, salve a configuração.
    Figura 24. Configurar o Servidor do KDC do Kerberos
    Configurar o Servidor do KDC do Kerberos

Testando a configuração do Kerberos do MPG do DataPower

Agora é possível executar um teste para determinar se sua nova configuração do MPG está devidamente configurada. Para tornar os testes o mais fácil possível de configurar, use o utilitário "curl" para enviar suas solicitações ao DataPower.

  1. Emita o comando curl para simular o navegador de um cliente enviando uma solicitação ao DataPower tendo como alvo o aplicativo snoop:
    curl -v --basic -u "mjmwasuser2:passw0rd" 
     http://l2dp1.rtp.raleigh.ibm.com:50000/snoop

    No comando acima, você está usando a opção --basic -u <nome de usuário:senha> para enviar um cabeçalho de autenticação básica na solicitação de HTTP, usando um nome de usuário e senha válidos do LDAP. Esse é o ID do usuário e a senha que autenticam o cliente com relação ao LDAP em sua política AAA. Se o ID do usuário for autenticado com sucesso, então, o DataPower gera um ticket de serviço do Kerberos e envia uma solicitação ao aplicativo snoop com esse token incluído como um cabeçalho de HTTP. Se tudo funcionar corretamente, e o token do Kerberos for autenticado corretamente pelo Application Server backend, então, a resposta será semelhante aos fragmentos mostrados na Listagem 1.

    Listagem 1. Comando curl de amostra para testar a configuração do Kerberos
    $ curl -v  -u "mjmwasuser2:wasUs3r2" http://l2dp1.rtp.raleigh.ibm.com:50000/snoop
    * About to connect() to l2dp1.rtp.raleigh.ibm.com port 50000 (#0)
    *   Trying 9.42.125.160... connected
    * Connected to l2dp1.rtp.raleigh.ibm.com (9.42.125.160) port 50000 (#0)
    * Server auth using Basic with user 'mjmwasuser2'
    > GET /snoop HTTP/1.1
    > Authorization: Basic bWptd2FzdXNlcjI6d2FzVXMzcjI=
    > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 
    NSS/3.13.1.0 zlib/1.2.3 libidn/1.18 libssh2/1.2.2
    > Host: l2dp1.rtp.raleigh.ibm.com:50000
    > Accept: */*
    >
    < HTTP/1.1 200 OK
    < X-Backside-Transport: OK OK
    < Connection: Keep-Alive
    < Transfer-Encoding: chunked
    ...
    ...
    ...
    <tr><td>javax.servlet.context.tempdir</td><td>/opt/ibm/
    SDP/runtimes/base_v7/profiles/WTE_APPSRV71/temp/localhostNode01/server1/
    DefaultApplication/DefaultWebApplication.war</td></tr>
    <tr><td>com.ibm.websphere.servlet.event.ServletContextEventSource
    </td><td>com.ibm.ws.webcontainer.webapp.WebAppEventSource@2e5f2e5f
    </td></tr>
    <tr><td>com.ibm.wsspi.portletcontainer</td><td>
    com.ibm.ws.portletcontainer.pcinvoker.PortletContainerImpl@7c627c62</td></tr>
    </table><BR><BR>
    </body></html>
    * Connection #0 to host l2dp1.rtp.raleigh.ibm.com left intact
    * Closing connection #0
    $

    Se o conteúdo do HTML da resposta for aberto com um navegador, será semelhante à Figura 25.

    Figura 25. Resposta do aplicativo snoop
    Resposta do aplicativo snoop

Análise do Probe

Uma ferramenta útil para analisar o fluxo de tráfego pelo DataPower e confirmar o comportamento correto é o utilitário "DataPower Probe". Como sua atividade final nos testes de sua configuração o MPG do Kerberos, você ativará o Probe para essa configuração e, em seguida, executará o teste de "curl" mais uma vez. Para ativar e validar um teste usando a ferramenta Probe, faça o seguinte:

  1. Acesse o painel principal do MPG para a configuração kerbDemoMPG e clique no link Show Probe , conforme mostrado na Figura 26.
    Figura 26. Mostrar link do Probe
    Mostrar link do Probe
  2. No painel Probe, clique no botão Enable Probe para ativar uma captura de análise, conforme mostrado na Figura 27.
    Figura 27. Botão Enable Probe
    Botão Enable Probe
  3. Execute o teste de curl novamente, conforme descrito acima. Após a execução desse teste, volte ao painel Probe e clique no botão Refresh . Agora poderá ver um novo registro do Probe exibido, conforme visto na Figura 28. O registro do Probe é precedido por um ícone de lupa.
    Figura 28. Registro do Probe capturado
    Registro do Probe capturado
  4. Clique no ícone de lupa para visualizar o registro do Probe. A partir do painel resultante, clique no ícone de AAA (o ícone de AAA quadrado mostrado na Figura 29). Se a solicitação tiver sido executada com sucesso, serão exibidos dois registros relacionados ao processamento de AAA - o registro "ldap-authen" e o registro "get-kerberos-apreq". Ambos os registros têm um link que pode ser clicado "(show nodeset)" para a solicitação e para a resposta. Um link de solicitação ou de resposta ausente para qualquer um desses dois registros indica um problema. Consulte a Figura 29.
    Figura 29. Rastreio de execução do Probe de AAA
    Rastreio de execução do Probe de AAA
  5. Para verificar se um token válido do Kerberos foi gerado, clique no link (show nodeset) nesse painel. Você verá um elemento de token <apreq> , conforme visto na Figura 30. O subelemento <spnego-apreq-base64> , que está contido nesse elemento, é passado ao servidor backend como um cabeçalho de HTTP (Figura 30).
    Figura 30. Token do Kerberos gerado
    Token do Kerberos gerado
  6. Por fim, de volta ao painel Probe, clique no ícone de lupa que aparece após o ícone da ação de AAA. A partir daí, clique na guia Headers . Verifique se é possível ver o cabeçalho "Authorization" com o conteúdo do subelemento <spnego-apreq-base64> anteriormente visualizado como parte do cabeçalho, conforme mostrado na Figura 31. Isso fornece a confirmação de que o processamento relacionado ao Kerberos foi bem-sucedido e que um token do Kerberos foi gerado para a solicitação realizada para o servidor backend.
  7. Se forem encontrados problemas, volte ao painel Probe principal no qual você ativou o Probe (consulta a Figura 27 ou a Figura 28) e clique no botão View Log para examinar as mensagens de log relacionadas ao teste com falha. Se necessário, acesse o painel Troubleshooting no DataPower e configure o Log Level para debug para que mensagens de log mais detalhadas sejam geradas. Em seguida, repita seus testes novamente e visualize as mensagens de log geradas.
    Figura 31. Cabeçalho Authorization de HTTP
    Cabeçalho Authorization de HTTP

Dicas para a resolução de problemas

Esta seção fornece alguns problemas comuns que podem ser encontrados ao configurar o DataPower para autenticação do Kerberos. A Tabela 1 mostra as resoluções associadas a cada um desses problemas.

Observações:

  • O Debug Log Level pode ser configurado navegando até Troubleshooting > Logging para aumentar o nível de criação de log para "Debug-Level".
  • O erro CWSPN0011E mencionado na Tabela 1 quase sempre requer rastreio adicional descrito no documento MustGather, Problems with Spnego.
Tabela 1. Resolução para problemas comuns
ProblemaSintomaResolução
SPN do Cliente inválido é usado para o Kerberos Client Principal em AAA Post Processing do DataPower. Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Kerberos error in post processing: Client principal 'HTTP/BADdpkerbclient.csupport.com@CSUPPORT.COM' not found in Kerberos KDC database
Use o SPN correto para o Kerberos Client Principal
SPN do Servidor inválido é usado para o Kerberos Server Principal em AAA Post Processing do DataPower. Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Kerberos error in post processing: Server principal 'HTTP/BADoc4102831681.csupport.com@CSUPPORT.COM' not found in Kerberos KDC database
Use o SPN correto para o Kerberos Server Principal.
Nome da região não incluído no SPN do Cliente ou do Servidor em AAA Post Processing do DataPower. Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Kerberos error in post processing: Invalid Kerberos principal name: 'HTTP/dpkerbclient.csupport.com'
Assegure que o nome da Região esteja incluído no Kerberos Client Principal e no Kerberos Server Principal (por exemplo, HTTP/dpkerbclient.csupport.com@CSUPPORT.COM).
SPN do Cliente errado usado para o Kerberos Client Principal em AAA Post Processing do DataPower. Nesse caso, o SPN do Cliente é um SPN válido no KDC, mas não é o SPN que corresponde à entrada SPN/key no arquivo keytab do cliente. Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Kerberos error in post processing: Kerberos KDC 'CSUPPORTKDC' required preauthentication that could not be provided
Assegure que o SPN usado no campo Kerberos Client Principal corresponda ao SPN no arquivo keytab do cliente.
SPN do Servidor errado usado para o Kerberos Server Principal em AAA Post Processing do DataPower. Nesse caso, o SPN do Servidor é um SPN válido no KDC, mas não é o SPN associado ao servidor backend ao qual a solicitação cliente se destina no fim. Isso faz com que o servidor backend receba um token de ticket de serviço que não pode decriptografar e geralmente resulta em um erro registrado pelo servidor backend e uma resposta de erro é retornada. Um token é gerado pelo DataPower e pode ser visto no Probe. Para um servidor backend alvo do WebSphere Application Server, segue uma mensagem de erro que poderá ser observada no log de rastreio do Application Server nessa circunstância:
0000000f Context E com.ibm.ws.security.spnego.Context begin CWSPN0011E: A non-valid SPNEGO token has been encountered while authenticating a HttpServletRequest: 0000: a1143012 a0030a01 01a10b06 092a8648 ..0. .... .... .*.H
Assegure que o SPN usado no campo Kerberos Server Principal seja o SPN correto para esse serviço. O administrador do WebSphere Application Server pode emitir um comando "klist" com relação aos arquivos keytab usados pelo Application Server para verificar qual é o valor do SPN do serviço.
A opção Checksum não está ativada em AAA Post Processing do DataPower. Se o servidor backend for configurado para esperar um valor de soma de verificação no token do ticket de serviço, isso geralmente resulta em um erro ser registrado pelo servidor backend e uma resposta de erro ser retornada. Um token é gerado pelo DataPower e pode ser visto no Probe. Para um servidor backend alvo do WebSphere Application Server, segue uma mensagem de erro que poderá ser observada no log de rastreio do Application Server nessa circunstância:
0000000f Context E com.ibm.ws.security.spnego.Context begin CWSPN0011E: A non-valid SPNEGO token has been encountered while authenticating a HttpServletRequest: 0000: a1143012 a0030a01 01a10b06 092a8648 ..0. .... .... .*.H
Assegure que o botão de opções "Generate GSS-API Checksum in the "AP-REQ" no painel de configuração Kerberos Client Keytab esteja selecionado (essa é a configuração de AAA).
Um Key Version Number (kvno) mais antigo ou diferente está associado ao SPN no arquivo keytab do cliente do que o existente no KDC para esse SPN.
Sintoma: Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Cannot parse file for Kerberos keytab 'dpkerbclientKeytab'
Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Cannot parse file for Kerberos keytab 'dpkerbclientKeytab'
Assegure que o kvno no arquivo keytab do cliente corresponda ao kvno associado a esse SPN no KDC. Use o comando "ldifde" na máquina do KDC Domain Controller para determinar qual valor de kvno é usado pelo KDC para o SPN em questão. Em seguida, use o utilitário "klist" em uma máquina do Linux para determinar o kvno no arquivo keytab (klist -k <arquivo keytab>). Se forem diferentes, crie um novo arquivo keytab para assegurar que seu kvno corresponda ao kvno usado pelo KDC.
Ao chamar o comando ktpass para criar o arquivo keytab e especificar explicitamente o Key Version Number (kvno) usando o parâmetro "-kvno", o kvno no arquivo keytab ainda não corresponde ao kvno no KDC. Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Cannot parse file for Kerberos keytab 'dpkerbclientKeytab'
Parece que algumas versões do ktpass, se não todas, forçam o kvno a ser incrementado no KDC toda vez que o arquivo keytab é gerado para um determinado SPN. Se o parâmetro "-kvno" for especificado na linha de comando, configura o kvno no arquivo keytab somente para o valor especificado. O kvno no KDC é incrementado para o próximo valor mais alto. Muitas vezes usuários usarão o comando "ldifde" no Domain Controller para obter o valor atual do kvno no KDC para um SPN específico e, então, chamarão o comando ktpass para criar um novo arquivo keytab que corresponda a esse kvno usando o parâmetro "-kvno". Isso não funciona, pois o kvno do KDC para esse SPN é incrementado como resultado da emissão do comando ktpass. Em vez disso, simplesmente emita o comando ktpass sem o parâmetro "-kvno" e o arquivo keytab resultante terá o mesmo
valor de kvno que o KDC.
O objeto Kerberos KDC Server, sob Objects > Crypto Configuration, não foi criado ou seu valor de "Kerberos realm name" não corresponde à região contida no valor de Kerberos Principal no painel AAA Post Processing. A distinção entre maiúsculas e minúsculas é relevante ao corresponder esses valores de região. Mensagem de nível de depuração vista no log de erro do DataPower:
mpgw (kerbDemoMPG): Kerberos KDC for realm 'CSUPPORT.COM' not found
Assegure que a região especificada no objeto Kerberos KDC Server corresponda à região especificada em Kerberos Principal Names no painel AAA Post Processing.
Ao monitorar o tráfego de rede ao testar a configuração do Kerberos do DataPower, parece não haver nenhuma comunicação de rede entre o DataPower e o servidor do KDC. Nenhum pacote de IP relacionado ao Kerberos é visto no fluxo entre o DataPower e o servidor do KDC ao capturar pacotes de rede durante os testes da configuração do Kerberos. No entanto, o DataPower ainda pode gerar tokens do Kerberos destinados ao servidor backend. O DataPower armazena em cache os tickets de serviço enviados do KDC, de forma que não solicita um novo ticket de serviço para cada solicitação. Nenhuma resolução é necessária, pois esse é um comportamento normal e correto no DataPower.

Conclusão

Este artigo demonstrou como realizar uma configuração de Multi-Protocol Gateway usando o DataPower WebUI, que permitiu que clientes autenticados não por Kerberos conectassem a um aplicativo da web do WebSphere Application Server backend que aceita solicitações somente de clientes autenticados por Kerberos. Como parte desta demonstração, você aprendeu como autenticar seus clientes usando um método de autenticação diferente e, em seguida, como enviar todas as solicitações ao servidor backend sob um único nome de principal do Kerberos.

Aprendeu também como gerar os artefatos necessários do Kerberos que sua configuração precisava e onde esses artefatos são usados e seus propósitos. Por fim, também viu uma maneira conveniente de testar sua configuração de MPG usando o utilitário "curl" e como solucionar problemas de nossa configuração se as coisas não funcionarem com sucesso desde o início.

Em nosso próximo artigo, vamos ver como gerar tokens do Kerberos de maneira mais programática usando o método dp:get-kerberos-apreq de folha de estilo do cliente do DataPower. Também vamos discutir por que usar essa abordagem e quais são as vantagens e desvantagens que ela tem com relação à abordagem que demonstramos neste artigo.


Suporte IBM

Se for necessária uma assistência adicional, reúna as informações MustGather a seguir e entre em contato com o Suporte IBM:

Recursos

Aprender

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=829739
ArticleTitle=Configurando um Servidor Backend Protegido por Kerberos do WebSphere DataPower, Parte 1: Usando a Interface Gráfica com o Usuário da Web do DataPower
publish-date=08102012