Introdução

Os pedidos de recursos corporativos foram expandidos para englobar não só os clientes organizacionais confiáveis, mas também os distantes e os não familiares. O sucesso de SOA resultou na publicação de aplicativos corporativos, como serviços a serem descobertos e processados de maneira dinâmica.

Especificações de SOA, como Web Services Description Language (WSDL), definiram a estrutura do modo de aplicativo, ao passo que mecanismos como IBM® WebSphere® Registry and Repository ou Universal Description Discovery and Integration (UDDI) foram criados para anunciar os locais dos serviços e os requisitos para executá-los. Os serviços que em outro momento estavam confinados a estruturas de programação de aplicativo predefinidas e codificadas permanentemente são agora acessadas fracamente acopladas.

Essa exposição de recursos foi acompanhada por um esforço para assegurar a autenticação robusta. A especificação WS-Security evoluiu para oferecer suporte ao uso de Security Assertion Markup Language (SAML), certificados X.509, bilhetes Kerberos e Username, além de outras formas de identificar a transmissão em um padrão de metadados unificado que oferece padronização para autenticação e autorização.

Como essas ferramentas evoluíram, os provedores de serviços procuraram estabelecer controle e políticas organizacionais agnósticas de aplicativo e plataforma. O protocolo WS-Policy e suas especificações de suporte, como Web Service Policy Framework, Policy Attachment, WS-SecurityPolicy e WS-ReliableMessagingPolicy, procuram estabelecer uma metodologia de unificação que pode ser descoberta e consumida à medida que os serviços são descobertos. Dessa forma, o acesso a grupos de serviços pode ser controlado em massa em vez de individualmente.

WS-Policy descreve a segurança e a qualidade dos requisitos de serviço em um formato legível pelo ser humano e pela máquina que facilita a criação automatizada de pedidos de serviço. Decisões de tempo de projeto podem ser tomadas para garantir que as credenciais corretas sejam enviadas ao serviço. Decisões de tempo de execução podem ser tomadas para autorização de pedidos individuais. O mais importante, WS-Policy na verdade não define a implementação de asserções, mas define os metadados que anunciam a asserção, descrevendo, por exemplo, que um serviço requer um Username. Isso depende da implementação Policy Decision Point (PDP), que interpreta os metadados de WS-Policy para elaborar a asserção real da existência do token Username (UNT).

Este artigo mostrará a implementação do controle de serviço WS-Policy para SOA via implementação e aplicação de uma configuração PDP no WebSphere DataPower® SOA Appliance (DataPower). DataPower trocará informações de identidade com um aplicativo hospedado no WebSphere Application Server. Com a transferência do gerenciamento de política para DataPower, o WebSphere Application Server tem melhor capacidade de proporcionar funcionalidade em nível de aplicativo, enquanto o DataPower proporciona controle de serviço de alto desempenho corporativo.

Introdução ao token LTPA

Os tokens geralmente são usados para transmitir a identidade no tráfego de mensagens. Exemplos de tokens são SAML, certificado X.509 e bilhetes Kerberos. Os tokens podem ser gerenciados e distribuídos por Secured Token Services (STS), conforme descrito pela especificação WS-Trust.

Os tokens Lightweight Third-Party Authentication (LTPA) são usados pelos produtos IBM WebSphere e IBM Lotus Domino. Os tokens LTPA contêm uma identidade assinada e criptografada simetricamente com uma chave com duração limitada que é compartilhada com entidades confiáveis. Esse procedimento oferece confidencialidade eficiente sem a fase de criação de chave de sessão típica que estabelece uma chave provisória para criptografia simétrica usada por tecnologias de criptografia assimétrica, como SSL/TLS. A chave compartilhada (segredo compartilhado) deve ser comunicada entre essas partes confiáveis antes do uso. O token LTPA é também usado para fornecer conexão única (SSO) em ou entre células do WebSphere Application Server.

Os tokens LTPA podem ser enviados entre processos e aplicativos WebSphere Application Server por meio de cabeçalhos de cookies HTTP ou em um token de segurança binário WS-Security. Sua natureza criptografada fornece a confidencialidade necessária para proteger as informações de identidade dentro dele.

Há inúmeras versões do token LTPA. Os tokens da Versão 1 contêm informações de região e identidade. A região é usada para associar o registro de usuário utilizado pelo WebSphere Application Server para autenticação. Os tokens mais recentes da Versão 2 apresentados no WebSphere Application Server V6 possuem atributos personalizados, mas a programação personalizada é necessária para acessá-lo e utilizá-lo.

Quando um aplicativo WebSphere Application Server ou Domino recebe um token LTPA, ele não precisa reautenticar o usuário, mas pode ainda precisar acessar o registro para criar um objeto Subject completo contendo informações, como associações de grupo.

O DataPower Appliance pode decriptografar e usar a identidade LTPA e usar novos tokens LTPA (o produto IBM Tivoli Access Manager WebSEAL também oferece esse recurso). A chave secreta compartilhada deve ser gerenciada entre os aplicativos DataPower e WebSphere Application Server, e questões como a duração de uma chave devem ser tratadas. Os recursos do WebSphere Application Server, como geração de chave automática, poderão causar falhas de decriptrografia se a nova chave não for comunicada corretamente. Por isso, pode ser melhor gerenciar a geração de chaves por meio de um processo com scripts ou intervenção manual. Devido aos recursos de desempenho e ao suporte no WebSphere Application Server e no DataPower, os tokens LTPA são em geral usados quando o DataPower é posicionado em frente dos servidores WebSphere Application Server.

Aplicativo de amostra

DataPower atende a uma função valiosa em um ambiente de aplicativo típico. Usando sua funcionalidade criptográfica otimizada para hardware criada para uma finalidade, o DataPower transfere operações que usam bastante o processador, como verificação de integridade de assinatura digital e criptografia e decriptografia de mensagem para confidencialidade. A transferência desse processamento intensivo permite à pilha do aplicativo processar as mensagens de modo mais eficiente, da forma como foi projetado.

Os clientes podem fazer pedidos de serviços que exigem informações de credenciais, para autenticar e autorizar o acesso ao aplicativo. O DataPower foi projetado para autenticar uma variedade de tokens de identidade, incluindo certificados X.509, tokens Username de WS-Security, certificados SSL e cabeçalhos de autenticação básica. A autorização pode ser feita para repositórios como diretórios LDAP ou por meio de aplicativos, como IBM Tivoli Access Manager.

O aplicativo de amostra combina autenticação com aplicação com o uso de políticas WS-Policy. A Figura 1 abaixo mostra uma topologia em que os clientes devem enviar pedidos contendo tokens WS-Security Username sobre SSL para garantir a confidencialidade das informações de identidade. As identidades são autenticadas e autorizadas para acesso a aplicativo. Todos os usuários autenticados recebem uma identidade de grupo, que deve ser armazenada em um token LPTA assinado. Esse token é criptografado simetricamente com o uso de um segredo compartilhado conhecido do DataPower e do WebSphere Application Server. A criptografia simétrica é composta por ordens de magnitude mais rápidas que a assimétrica.

Quando o WebSphere Application Server recebe o token LTPA, ele decriptografa usando o segredo compartilhado, extrai as informações de identidade contidas e as utiliza para autenticar o pedido e estabelecer uma identidade JEE. Esse aplicativo simples apenas repete uma cadeia de caractere contida na mensagem de pedido e anexa a ela a identidade JEE fornecida pelo tempo de execução.

As implementações de PDP com DataPower e WebSphere Application Server são usadas para garantir a conformidade. No DataPower, uma política valida a existência de um token WS-Security Username. No WebSphere Application Server, uma política verifica o requisito de um token LPTA nos metadados da mensagem de pedido. Nosso exemplo inicia com a configuração do WebSphere Application Server, seguida pela implementação do DataPower.

Configurando o WebSphere Application Server

Esta seção mostra como configurar um provedor de serviços Web do WebSphere Application Server V7 para consumir um token LTPA e defini-lo como o contêiner da identidade do solicitante do serviço.

A configuração da qualidade de serviço do serviço Web no WebSphere Application Server V7 é feita por meio de ligações e conjuntos de políticas. A terminologia de políticas do WebSphere Application Server é um pouco diferente da terminologia de WS-Policy. O que o WebSphere Application Server chama de política, o WS-Policy chama de expressão de política -- um conjunto de metadados que descreve uma regra ou um requisito de serviço. O WebSphere Application Server também usa o termo conjunto de políticas, que é simplesmente um conjunto de instâncias de política. O WebSphere Application Server tem várias políticas, como WS-Security, WS-Addressing e transporte de HTTP. Os conjuntos de políticas reúnem políticas em entidades únicas e configuráveis. Por exemplo, um dos conjuntos de políticas predefinidos do WebSphere Application Server, o Kerberos V5 HTTPS padrão, é composto por instâncias de WS-Security, WS-Addressing e políticas de transporte de SSL.

Um conjunto de política informa qual é a configuração, mas não lhe informa como obtê-la. Por exemplo, ele diz que o corpo do pedido SOAP deve ser criptografado, mas não diz como criptografá-lo -- ele não fornece os keystores de certificado. É para isso que serve a ligação -- a ligação é a entidade que fornece as informações de variável, como keystores.

A partir dessa breve introdução, você verá que há três entidades no WebSphere Application Server com as quais você trabalhará: um conjunto de políticas, uma ligação e o aplicativo. Você anexa um conjunto de políticas a um aplicativo e atribui uma ligação a esse aplicativo. O restante desta seção mostra como criar um conjunto de políticas, criar uma ligação, vincular o novo conjunto de políticas a um aplicativo e atribuir a ligação a esse mesmo aplicativo.

Criar o conjunto de políticas de LTPA

É possível criar um conjunto de políticas do zero, mas o WebSphere Application Server vem com um número predefinido de conjuntos de políticas, e um está perto do que você precisa: Padrão LTPA WSSecurity. Portanto, em vez de criar um, é possível criar uma cópia e modificá-la. O conjunto de políticas padrão LTPA WSSecurity lida com um token LTPA, que é o que você quer. Mas ele também assina e criptografa a mensagem, o que é desnecessário. Em vez de assinar a mensagem, é preciso deixar SSL fazer a criptografia. A Figura 2 abaixo mostra a seção do Administrative Console de que a cópia é iniciada:

1. Navegue para Services => Policy sets => Application policy sets.
2. Selecione o padrão LTPA WSSecurity e clique em Copy.
3. No painel que segue, escolha um nome para o seu novo conjunto de políticas, como LTPA sobre SSL.
4. Forneça uma descrição de sua preferência e clique em OK:
   
   Figura 2. Copiar o conjunto de políticas LPTA predefinido
   
   
   

Após ter criado a sua cópia, você a verá na lista de conjuntos de políticas, como mostra a Figura 3. Os conjuntos de políticas predefinidos não são editáveis, mas o novo conjunto de políticas LTPA sobre SSL é. Clique em LTPA over SSL para editá-lo. A janela na Figura 4 é exibida.

A Figura 4 mostra que o conjunto de políticas é composto por duas instâncias de política: WS-Addressing e WS-Security. É preciso adicionar SSL à configuração:

1. Clique no menu suspenso Add.
2. Selecione o transporte SSL na lista de políticas disponíveis.

Você pode examinar a nova instância de política SSL clicando nela. Os valores padrão são suficientes. É tudo o que precisa ser feito para ativar SSL.

Agora é preciso editar a instância de política WS-Security. Na janela na Figure 4, navegue WS-Security => política Main:

O que precisamos fazer aqui é desativar a proteção de mensagens desmarcando essa caixa. A proteção de WS-Security não está sendo feita, e não estamos fazendo a assinatura -- em vez disso, estamos contando com SSL para criptografia. É tudo o que precisamos alterar na sua versão do conjunto de políticas LTPA.

Criar a ligação

O WebSphere Application Server vem com ligações predefinidas padrão. A ligação padrão funciona na forma em que se encontra para o conjunto de políticas LTPA sobre SSL: O token LTPA é validado e consumido pelo mecanismo SOAP, e a chamada para o provedor de serviços Web é feita com êxito. Entretanto, queremos dar um passo adiante. Com a ligação padrão, a identidade é consumida pelo mecanismo SOAP -- ela não é passada para a implementação do serviço Web. Queremos a identidade do chamador -- a identidade contida no token LTPA -- a ser passada para a implementação. Portanto, precisamos de um pouco mais do que o disponível na ligação padrão.

Poderíamos criar uma ligação do zero, mas isso significaria criar muita configuração que já existe na ligação padrão, portanto, faremos uma cópia e a editaremos. Para fazer uma cópia da ligação do lado do provedor:

1. Navegue para Services => Policy sets => General provider policy set bindings.
2. Faça uma cópia da amostra Provider da mesma forma que copiou o conjunto de políticas LTPA padrão. Dê um nome à amostra de provedor Demo.
3. Nesse ponto, como uma etapa adicional, se você quiser poupar um pouco de tempo no futuro, poderá definir a amostra de provedor Demo como a ligação de provedor padrão. Navegue para Services => Policy sets =>Default policy set bindings, e defina a amostra de provedor Demo como o padrão.
4. Para criar a nossa alteração, acesse a instância de política WS-Security da nova ligação. Será exibido primeiro o painel esquerdo:
   
   Figura 6. Criar o responsável pela chamada
   
   
   
5. O responsável pela chamada define qual token, se houver, é usado como o ID do responsável pela chamada na implementação. (Uma mensagem pode conter zero ou mais tokens -- no nosso caso, conterá um.) Avance para o próximo painel clicando em Caller. Por padrão, é possível ver que não há nenhuma identidade de responsável pela chamada. Para adicionar uma, clique em New:
   
   Figura 7. Configurar o responsável pela chamada
   
   
   
6. Nesta janela, dê à configuração de responsável pela chamada qualquer nome desejado -- o nome na verdade não importa. Entretanto, os valores nos próximos dois campos têm bastante importância -- tome cuidado com erros de digitação. Esses dois campos definem o nome completo do token da mensagem a ser usada como a identidade do responsável pela chamada, e esses valores devem corresponder exatamente ao que estará na mensagem SOAP. Clique em Apply.

É possível imaginar onde exatamente encontrar os valores corretos para os campos de espaço de nomes e parte local. Para este artigo, nós os fornecemos. Mas quais serão os valores se você quiser usar outros tipos de token? Se tiver memorizado completamente as várias especificações de WS-Security e as páginas do centro de informações desses tópicos, você simplesmente saberá o que elas são. Mas, a maioria de nós não consegue guardar grande parte dessas informações em nossas cabeças, portanto, há um espaço no console do administrador onde o assistente preenche esses valores para nós. É possível usar essa página como referência:

1. Navegue até qualquer ligação que tenha a política WS-Security.
2. Navegue dessa ligação para WS-Security => Authentication and protection => New token (em Authentication tokens) => Token generator.
3. Selecione o tipo de token desejado.
4. O assistente preenche os campos "Local part" e "Namespace URI", conforme mostra a Figura 8 abaixo. Esses campos correspondem aos campos "Caller identity local part" e "Caller identity namespace URI", respectivamente, no painel na Figura 7 acima.
   
   Figure 8. Localizar o nome completo de um determinado tipo de token
   
   
   

Anexar o conjunto de políticas

Nas seções anteriores, você criou um conjunto de políticas e uma ligação. Agora, é preciso configurar um aplicativo com esse conjunto de políticas e essa ligação. Para esse exemplo, use uma variante da amostra EchoService, que faz parte das amostras de JAX-WS que vêm com o WebSphere Application Server. (Caso tenha optado por não instalar amostras quando instalou WebSphere Application Server, você poderá usar a versão dessa amostra que vem com este artigo.)

1. Navegue até Services => Service providers => EchoService, como mostra a Figura 9 abaixo.
2. Selecione EchoService.
3. Clique em Attach Policy Set e selecione a política recém-criada no menu suspenso:
   
   Figura 9. Anexar nosso conjunto de políticas LTPA ao aplicativo de provedor
   
   
   

Ao concluir essas etapas, o LTPA sobre SSL é mostrado como o conjunto de políticas anexo, e a ligação será a padrão.

Atribuir a ligação

Caso seja a ligação de amostra de provedor Demo seja definida como padrão, não será preciso fazer nada aqui; a ligação padrão será atribuída automaticamente. Se ela não tiver sido definida como padrão:

1. Selecione o serviço na janela mostrada na Figura 9 acima.
2. Clique em Assign Binding para exibir o menu suspenso de ligações.
3. Selecione a mostra de provedor Demo.

O aplicativo usado neste artigo

Conforme mencionado, o aplicativo usado neste artigo é uma variante do aplicativo EchoService que faz parte das amostras que acompanham o WebSphere Application Server. Fique à vontade para usar a amostra EchoService que acompanha o WebSphere Application Server, mas com essa versão do aplicativo, não há nenhuma prova pronta de que a identidade no token LTPA chegou ao serviço. Para as finalidades de demonstração, modificamos o aplicativo EchoService para que ele repita não só a cadeia de caractere de entrada, mas também a identidade do responsável pela chamada, como indicado no resultado de exemplo em Listagem 6 na seção DataPower abaixo, dessa forma provando que a identidade realmente vai do DataPower para o aplicativo WebSphere Application Server. Se quiser usar a amostra modificada, será possível fazer o seu download na parte inferior do artigo.

Integrando WebSphere Application Server e DataPower -- o arquivo de chave LTPA

Exportar o arquivo de chave LTPA do WebSphere Application Server

Até esse ponto, você configurou um aplicativo WebSphere Application Server para aceitar mensagens de pedido de token LTPA. O remetente, em nosso caso, DataPower, deve saber algo sobre a configuração LTPA do WebSphere Application Server. Essas informações são armazenadas em um arquivo de chave LTPA, portanto, é preciso exportá-lo para que o DataPower possa importá-lo depois. Para exportar esse arquivo:

1. Em Authentication, selecione Security => Global security => LTPA.
2. Em Cross-cell single sign-on, conforme mostra a Figura 10 abaixo, digite uma senha de sua escolha. Essa senha será necessária ao importar o arquivo de chave para o DataPower.
3. Especifique um nome de arquivo de chave e clique nas teclas Export:
   
   Figura 10. Exportar o arquivo de chave LTPA do WebSphere Application Server
   
   
   

Há uma coisa de que é preciso estar ciente ao exportar chaves LTPA. O WebSphere Application Server automaticamente gera de novo as chaves LTPA com o tempo. Ao exportar as chaves LTPA, em algum ponto, as chaves no arquivo exportado não funcionarão mais. Para mantê-las funcionando, é possível desativar a geração automática de chaves LTPA. Ao fazer isso, você mesmo deverá gerenciar a nova geração de chaves em vez de esperar que o WebSphere Application Server faça isso.

Para desabilitar a nova geração automática de chaves, na Figura 10, clique nos grupos de conjuntos de chaves (Key) em "Key generation" no topo do painel. Em seguida, clique no seu grupo de conjuntos de chaves -- neste exemplo, NodeLTPAKeySetGroup. No painel mostrado na Figura 11, desmarque caixa de seleção Automatically generate keys em "Key generation".

Importar o arquivo de chave LTPA no DataPower

Carregue o arquivo de chave LTPA no diretório DataPower Appliance's cert://. Você verá na discussão sobre a configuração do DataPower como a política de Autenticação, Autorização e Auditoria (AAA) do dispositivo cria um token LTPA usando essa chave LTPA.

Configuração do DataPower

O DataPower foi projetado para atuar como um ponto de execução de política (PEP) para WS-Policy, que é suportado no objeto de serviço Web Service Proxy (WSP). No firmware DataPower release 3.7.3 ou posterior, as seguintes especificações de WS-Policy são suportadas:

• WS-Policy 1.2 e 1.5
• Web Service Policy Framework e Policy Attachment 1.5
• WS-SecurityPolicy 1.2 e 1.5
• WS-ReliableMessagingPolicy 1.2

O WS-Policy Attachment oferece suporte para WS-Policy criada no documento WSDL. Além disso, a políticas podem ser anexadas a vários assuntos WSDL, como mensagem, serviço, ligação ou operação, que usam a GUI do WS-Proxy. O suporte para domínios WS-Policy padrão, como WS-Security, é implementado por meio de modelos fornecidos no diretório store://policies//templates do DataPower Appliance. Nele, você encontrará modelos predefinidos para executar ações de política padrão, como execução de assinaturas digitais, criptografia, presença do token Username e uso de protocolos protegidos, entre outros modelos de política.

Na configuração DataPower abaixo, você configurará um WSP para oferecer suporte aos requisitos do aplicativo de amostra e sua interação com as restrições de WS-Policy impostas pelo aplicativo WebSphere Application Server. São eles:

• Usar WS-Policy para solicitar o token Username mediante pedido do cliente
• Solicitar transporte seguro mediante solicitação do cliente
• Converter token Username em cabeçalho WS-Security com token LTPA

A configuração básica do WSP é considerada, portanto, a ênfase aqui está nos requisitos principais de WS-Policy, e algumas etapas básicas não relacionadas não são mostradas. Para mais informações sobre a configuração básica de WSP, consulte a Documentação de WebSphere DataPower SOA Appliances ou o Manual do WebSphere DataPower SOA Appliance.

Configuração de mensagem de pedido recebido

A primeira etapa para configurar o WSP é criar o WSP e atribuir o WSDL. O serviço no WebSphere Application Server expõe o WSDL usando o URL https://9.30.197.37:9443/WSSampleSei/EchoService?WSDL. O WSDL é obtido e carregado no diretório local:// do dispositivo via WebGUI de gerenciamento de arquivos. A Figura 12 mostra a atribuição do WSDL para o WSP UNT-LTPA-Proxy recém-criado:

DataPower oferece suporte a métodos alternativos de atribuição de WSDL. É possível usar Universal Description Discovery and Integration (UDDI) ou WebSphere Service Registry and Repository para buscar o WSDL. WebSphere Service Registry and Repository pode ser usado para definir intervalos de sondagem a fim de buscar alterações no WSDL. Por exemplo, se o local do serviço remoto (o aplicativo WebSphere Application Server) mudar, o WSP poderá ser configurado para usar automaticamente o novo URL. Para mais informações sobre UDDI ou WebSphere Service Registry and Repository, consulte a Documentação de WebSphere DataPower SOA Appliances.

O WSDL contém um único serviço que expõe uma única porta para tráfego de mensagens. Essa porta é exposta em HTTPS e é o terminal onde o DataPower encaminhará pedidos validados ao EchoService. A Listagem 1 mostra a seção de serviço do WSDL:

Listagem 1. Atribuições de porta de serviço de WSDL

<wsdl:service name="EchoService">
   <wsdl:port name="EchoServicePort" binding="tns:EchoSOAP">
     <soap:address location="https://9.30.197.37:9443/WSSampleSei/EchoService"/>
   </wsdl:port>
</wsdl:service>

O DataPower pode expor várias portas de protocolo frontal para receber tráfego do cliente. Nesse caso, uma porta HTTPS é fornecida. Por padrão, o endereço remoto contém as informações de terminal da porta WSDL. Isso poderá ser alterado, se necessário, e também ser dinamicamente atribuído se, por exemplo, o terminal for diferente para classes diferentes de pedido, como um serviço de alta velocidade para clientes "gold", e um provedor de serviço de qualidade mais baixa para tráfego normal. A atribuição dinâmica é executada via ação Route da política DataPower ou no XSLT em uma ação Transformation. A Figura 13 mostra a atribuição de terminais locais e remotos:

O manipulador de terminal local é um Front Side Protocol Handler (FSH) denominado untLTPA_HTTPS_FSH -- um HTTPS FSH básico que aceita tráfego na porta 8082. Você agora definiu um WSP simples que aceita tráfego HTTPS e o encaminha a HTTPS://9.30.197.37:9443/WSSampleSei/EchoService.

A próxima etapa de configuração é usar WS-Policy para assegurar que os pedidos de cliente tenham o token Username conforme solicitado pelo nosso aplicativo de amostra. Todas as atribuições de WS-Policy são feitas na guia WSP Policy. A política pode ser anexada em cada nível do WSDL: serviço, proxy, operação e o próprio WSDL. Quando anexada, ela poderá ser executada em todos os níveis subsequentes -- por exemplo, a política anexada ao serviço está no nível de operação. É preciso assegurar que todo o tráfego de todos os serviços tenha UNT, o que pode ser feito por meio do botão WS-Policy:

Os requisitos são assegurar que o UNT seja fornecido em todos os pedidos do cliente. Conforme mencionado, o DataPower suporta WS-SecurityPolicy 1.2. A especificação WS-SecurityPolicy 1.2 contém as políticas de asserção de token Username que podem ser usadas para afirmar a existência desse token. DataPower sendo um PDP (ponto de decisão de política) fornece a implementação para esta e outras políticas de asserção de token.

DataPower contém um modelo de amostra no diretório store://policies//templates denominado wsp-sp-1-1-usernametoken.xml, que está próximo de nosso requisito.

A especificação WS-SecurityPolicy 1.2 contém opções para muitas variações da asserção UsernameToken. Por exemplo, variações do atributo sp:IncludeToken mudam o requisito da existência do UNT nas mensagens de pedido e/ou de resposta. Nem toda variação é suportada por um modelo preexistente no DataPower, portanto, em alguns casos, pode ser necessário modificar os modelos de DataPower. Há um modelo no DataPower para afirmar a existência do UNT nas mensagens de pedido e resposta. Não existe nenhum modelo preexistente para asserção no UNT na mensagem de pedido apenas, mas é possível criar um.

A Listagem 2 mostra uma seção desta política. Esta política está procurando um UNT no formato 1.1. O modelo também possui uma política que procura o UNT formato 1.0.

Listagem 2. Fragmento wsp-sp-1-1-usernametoken.xml

<wsp:All>
   <sp:SupportingTokens>
      <sp:UsernameToken sp:IncludeToken=
      "http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always">
         <wsp:Policy>
            <sp:WssUsernameToken11/>
         </wsp:Policy>
      </sp:UsernameToken>
   </sp:SupportingTokens>
</wsp:All>

Na especificação WS-SecurityPolicy 1.2 na seção 5.1.1 Valores de inclusão de token está a seguinte descrição (Tabela 1) de expectativas de token, conforme determinado pelo atributo sp:IncludeToken:

Descrição de WS-Security Policy sp:IncludeToken

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Never

O token NÃO DEVE ser incluído em nenhuma mensagem enviada entre o inicializador e o destinatário; em vez disso, uma referência externa para o token deve ser usada.

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Once

O token DEVE ser incluído em apenas uma mensagem enviada do inicializador para o destinatário. Referências para o token PODEM usar um mecanismo de referência interno. Mensagens relacionadas subsequentes enviadas entre o destinatário e o inicializador podem se referir ao token com o uso de um mecanismo de referência externo.

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient

O token DEVE ser incluído em todas as mensagens enviadas do inicializador para o destinatário. O token NÃO DEVE ser incluído em mensagens enviadas do destinatário para o inicializador.

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToInitiator

O token DEVE ser incluído em todas as mensagens enviadas do destinatário para o inicializador. O token NÃO DEVE ser incluído em mensagens enviadas do inicializador para o destinatário.

http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/Always

O token DEVE ser incluído em todas as mensagens enviadas entre o inicializador e o destinatário. Esse é o comportamento padrão.

O valor de http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200512/IncludeToken/Always, quando atribuído ao atributo sp:IncludeToken, requer um UNT no pedido e na resposta ao cliente. O requisito é para solicitar apenas o UNT no pedido. Por isso, é possível alterar o atributo sp:IncludeToken para http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient, que requer apenas o UNT na mensagem de pedido e não na resposta.

Em vez de modificar a política em store://policies//templates (o que você não tem permissão para fazer), copie isso para local://, renomeie para wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml, além de executar a alteração AlwaysToRecipient já mencionada.

Agora que uma política personalizada foi criada, ela precisa ser anexada ao nível de serviço do WSDL. A Figura 15 mostra a janela pop-up exibida ao se clicar no botão WS-Policy. A guia Sources é usada para atribuir a política. Navegar até o diretório local:// permite selecionar a política wsp-sp-1-1-usernametoken_AlwaysToRecipient.xml recém-criada.

Alguns documentos de política terão várias políticas diferenciadas por um atributo wsu:Id exclusivo. Ao encontrar o referido documento, designe qual usar selecionando o wsu:Id apropriado. Nesse exemplo, há somente um. Clique em Attach Source e Apply para que o WSP conclua a atribuição:

A política UNT não requer nenhuma informação adicional, mas algumas políticas exigem parâmetros para conclusão. Por exemplo, uma política que executa assinatura digital requer o nome de um certificado criptografado do DataPower para verificar a assinatura. A guia Processing permite atribuir essas propriedades. Além disso, a guia Enabled Subject permite ajustar com precisão os elementos de WSDL e as fase de mensagem a que a política é aplicada. Por exemplo, é possível executar a política apenas na fase de pedido de uma mensagem e não na resposta.

Se você enviar uma única solicitação a esse serviço via DataPower sem o UNT, ocorrerá uma violação. A Listagem 3 mostra um EchoRequest sem o UNT:

Listagem 3. EchoRequest de amostra sem UNT

<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope 
    xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
       oasis-200401-wss-wssecurity-secext-1.0.xsd"
    xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
       oasis-200401-wss-wssecurity-utility-1.0.xsd" 
    xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" 
    xmlns:tns="http://com/ibm/was/wssample/sei/echo/"     
    xmlns:xs="http://www.w3.org/2001/XMLSchema">
    <S11:Body>
        <tns:echoStringInput>
            <echoInput> Are you talkin' to me?</echoInput>
        </tns:echoStringInput>
    </S11:Body>
</S11:Envelope>

Usando cURL (http://www.haxx.se/), é possível enviar essa solicitação e ver os resultados. A Listagem 4 mostra a resposta do DataPower:

Listagem 4. Retorno de mensagem de erro sem UNT

 
curl -k -d @echoRequestNoUNT.xml 
https://9.33.96.224:8082/WSSampleSei/EchoService -H "Content-type: 
text/xml" -H "SOAPAction: echoOperation" --key WSTC-privkey.pem --cert WSTC-sscert.pem

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
<env:Body><env:Fault><faultcode>env:Client</faultcode><faultstring>
Required elements filter setting reject: expression /*[local-name()='Envelope' 
and (namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' 
or namespace-uri()='http://www.w3.org/2003/05/soap-envelope')]/*[local-name()='Header' 
and (namespace-uri()='http://schemas.xmlsoap.org/soap/envelope/' 
or namespace-uri()='http://www.w3.org/2003/05/soap-envelope')]//*[local-name()=
'UsernameToken' and namespace-uri()='http://docs.oasis-open.
org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd'] 
was not satisfied (from client)</faultstring></env:Fault></env:Body></env:Envelope> 

A adição de um UNT para o pedido, conforme visto na Listagem 5, deverá atender aos requisitos da política recém-adicionada. O UNT foi adicionado ao elemento wsse:Header, wsse:Security:

Listagem 5. EchoRequest com UNT

<?xml version="1.0" encoding="UTF-8"?>
<S11:Envelope xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-secext-1.0.xsd" 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/
oasis-200401-wss-wssecurity-utility-1.0.xsd" 
xmlns:S11="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:tns="http://com/ibm/was/wssample/sei/echo/" 
xmlns:xs="http://www.w3.org/2001/XMLSchema">
<S11:Header>
<wsse:Security>
<wsse:UsernameToken wsu:Id="username">
<wsse:Username>fred</wsse:Username>
<wsse:Password>flintstone</wsse:Password>
</wsse:UsernameToken>
</wsse:Security>
</S11:Header>
<S11:Body>
<tns:echoStringInput>
<echoInput>Are you talkin' to me?</echoInput>
</tns:echoStringInput>
</S11:Body>
</S11:Envelope>

Configuração de mensagem de pedido realizado

Antes de enviar uma solicitação ao aplicativo WebSphere Application Server, haverá um pouco mais de trabalho para ser feito. WebSphere Application Server está aplicando a identidade do solicitante ao token LTPA. Além disso, embora seja possível deixar vários clientes fazer pedidos, o WebSphere Application Server está configurado apenas para um único usuário desse aplicativo, portanto, é preciso mapear as solicitações validadas para um nome distinto aceito para WebSphere Application Server por meio da ação AAA da política de processamento. A Figura 16 mostra a regra de pedido padrão com a adição de uma política AAA:

A política AAA aceita as credenciais do cliente do UNT, conforme indica a Figura 17, que mostra a fase de extração de identidade da ação AAA:

Embora um aplicativo real use um mecanismo como LDAP para autenticar as credenciais de UNT, este exemplo usa um arquivo AAA Info XML armazenado no dispositivo. A Figura 18 mostra a fase de autenticação:

O arquivo AAA Info proporciona uma forma conveniente de atribuir a nova credencial para WebSphere Application Server. É possível usar métodos alternativos, como Tivoli Federated Identity Manager, Secured Conversation ou vários métodos personalizados, como consulta xPath, no documento de pedido ou XSLT do cliente. A Figura 19 mostra o mapeamento do arquivo AAA Info:

A etapa final no processamento de AAA é converter o UNT no token LTPA. Nessa fase de pós-processamento, Generate LTPA Token foi selecionado. A opção padrão é armazenar o token LTPA em um cabeçalho HTTP Cookie. Opcionalmente, o token pode ser armazenado no elemento de cabeçalho WS-Security, e essa opção foi escolhida aqui. DataPower oferece uma caixa suspensa (LTPA Token Version), a qual é usada para designar o formato do token LTPA. Os objetivos são selecionar a versão do token (V1/V2) e se deve ser usado um HTTP Cookie ou um Binary Security Token (BST) para conter o token. Além disso, há duas formas de BST (geralmente usadas com tráfego de serviço Web) disponíveis com diferentes declarações de espaço de nomes.

As opções de versão de token LTPA de Domino, WebSphere Versão 1 e WebSphere Versão 2 são autoevidentes. FIPS WebSphere Versão 1 oferece segurança aprimorada compatível com Federal Information Processing Standard (FIPS) para o token Versão 1 (o token Versão 2 é inerentemente compatível com FIPS). E WebSphere V7 Versão 2 é usado para criar um BST com o espaço de nomes wwst:LTPAv2Outgoing request. Esses valores passaram por revisão quando este artigo foi publicado, portanto, será preciso verificar os guias de produto DataPower para ver as informações mais recentes sobre a revisão de firmware. A Figura 20 mostra a seleção de LTPA:

Referindo-se novamente à introdução de LTPA, há inúmeras versões do token LTPA. Selecionamos o formato WebSphere V7.0 Versão 2. Além disso, o arquivo de chave LTPA, como obtido do WebSphere Application Server (veja a discussão na configuração do WebSphere Application Server) é carregado no diretório cert:// do dispositivo, e a senha é inserida. Os atributos de usuário LTPA poderiam ter sido fornecidos. Esses pares de nome-valor requerem programação de aplicativo no aplicativo WebSphere Application Server para consumo e interpretação.

A conclusão da ação AAA finaliza a configuração da política WSP. As solicitações enviadas ao aplicativo por meio do dispositivo DataPower são agora validadas pelo WSP e pelo WS-Policy. Os tokens Username são convertidos em tokens LTPA pela política AAA e enviados ao aplicativo WebSphere Application Server. A Listagem 6 mostra um exemplo de um pedido e uma resposta com o uso de cURL. As respostas de aplicativo com a cadeia de caractere repetida e o username (wsadmin), como extraído do token LTPA.

Listagem 6. Envio da solicitação por meio de DataPower

curl -k -d @echoRequest.xml https://9.33.96.224:8082/WSSampleSei/EchoService -H 
"Content-type: text/xml" -H "SOAPAction: echoOperation" 
--key WSTC-privkey.pem --cert WSTC-sscert.pem

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Body><ns2:echoStringResponse xmlns:ns2="http://com/ibm/was/wssample/sei/echo/">
<echoResponse>JAX-WS==>> Are you talkin' to me? (user: wsadmin)</echoResponse>
</ns2:echoStringResponse></soapenv:Body>
</soapenv:Envelope>

Conclusão

WS-Policy foi desenvolvido para oferecer controle de SOA corporativo. Este artigo mostrou seu uso e sua implementação no WebSphere DataPower SOA Appliance para a execução de tokens Username e no WebSphere Application Server para a execução de tokens LTPA. Os tokens LTPA são um método eficiente de conexão única ao fornecer informações de identidade que não precisam ser autenticadas novamente.

Recursos

• IBM Redbook: Web Services Feature Pack for WebSphere Application Server V6.1
  Boa descrição do uso de conjuntos de políticas e ligações no WebSphere Application Server.
  
  
• Web Services Policy 1.5 -- Primer
  Descrição introdutória da linguagem de Web Services Policy, com o uso de numerosos exemplos.
  
  
• Web Services Policy 1.5 -- Framework
  Modelo de finalidade geral e sintaxe correspondente para descrever as políticas das entidades em um sistema baseado em serviços Web. Web Services Policy Framework define um conjunto base de construções que pode ser usado e ampliado por outras especificações de serviços Web para descrever uma ampla gama de recursos e requisitos de serviço.
  
  
• Web Services Policy 1.5 -- Attachment
  Definição de dois mecanismos de finalidade geral para a associação de políticas, conforme definido em Web Services Policy 1.5 -- Framework, com os assuntos a que eles se aplicam. Essa especificação também define como usar esses mecanismos de finalidade geral para associar políticas a descrições de WSDL e UDDI.
  
  
• WS-Security Policy 1.2
  Descrição da Versão "200512 do espaço de nomes WS-SecurityPolicy, além de links para recursos relacionados com o uso de Resource Directory Description Language (RDDL) 2.0.
  
  
• Página de recursos para desenvolvedores de WebSphere DataPower SOA Appliances
  Recursos técnicos que ajudam a utilizar os WebSphere DataPower SOA Appliances para fins de simplificação, proteção e aceleração das implementações de serviços da Web e XML dentro de uma SOA.
  
  
• Página do produto WebSphere DataPower SOA Appliances
  Descrições e novidades de produtos, informações de treinamento, informações de suporte, e mais.
  
  
• Biblioteca de produtos WebSphere DataPower SOA Appliances
  Anúncios sobre produtos, casos de referência, White Papers, e mais.
  
  
• Documentação de WebSphere DataPower SOA Appliances
  Documentação completa dos dispositivos DataPower XA35, XS40, XI50, XB60 e XM70.
  
  
• Suporte a WebSphere DataPower SOA Appliances
  Um banco de dados pesquisável de problemas de suporte e suas soluções, além de downloads, correções, rastreio de problemas, e mais.
  
  
• Fórum WebSphere DataPower SOA Appliances
  Obtenha respostas às suas perguntas técnicas e compartilhe seu conhecimento com outros usuários do WebSphere DataPower.
  
  
• Manual de dispositivo SOA WebSphere DataPower
  Este livro disponível no mercado editorial mostra como usar os dispositivos DataPower a partir das perspectivas de rede, segurança e ESB. O livro descreve a instalação, a configuração, o gerenciamento, o monitoramento, a configuração, a compilação, a implementação, o DataPower como um dispositivo de rede e os serviços DataPower, especialmente os "três grandes": XML Firewall, Web Service Proxy e Multi-Protocol Gateway.
  
  
• IBM Redbook: IBM WebSphere DataPower SOA Appliances, Parte I: Visão geral e primeiros passos
  DataPower SOA Appliances são dispositivos de rede que se destinam a fins específicos, fáceis de implementar, que simplificam, protegem e aceleram as implementações de serviços da Web e XML enquanto estende a infraestrutura da SOA. Este IBM Redbook descreve a arquitetura DataPower, casos de referência, cenários e detalhes da implementação, além das boas práticas da arquitetura orientada a mensagens SOA em um ambiente ESB de legado.
  
  
• IBM Redbook: IBM WebSphere DataPower SOA Appliances Parte II: Autenticação e autorização
  Este IBM Redbook inclui os seguintes tópicos de autenticação e autorização do DataPower: conceitos básicos, criação de políticas, uso do Tivoli Access Manager e uso dos diretórios LDAP.
  
  
• IBM Redbook: IBM WebSphere DataPower SOA Appliances Parte III: Guia de segurança XML
  Este IBM Redbook descreve como usar um dispositivo DataPower para proteger Serviços da Web de entrada em um ambiente SOA, como integrar seu dispositivo DataPower com o WebSphere Message Broker e como se proteger contra ataques de segurança implementando o XML Denial of Service (XDoS) fornecido pelos dispositivos DataPower.
  
  
• IBM Redbook: IBM WebSphere DataPower SOA Appliances Parte IV: Gerenciamento e controle
  Este IBM Redbook descreve como integrar um dispositivo DataPower com outros produtos como o WebSphere Registry and Repository, o IBM Tivoli Composite Application Manager for SOA e o Tivoli Composite Application Manager System Edition.
  
  
• IBM Redpaper: WebSphere DataPower SOA Appliances: A interface de gerenciamento de XML
  Este IBM Redpaper descreve a interface XML Management, que é o terceiro modo de configurar e administrar o WebSphere DataPower SOA Appliance, além das interfaces WebGUI e CLI.
  
  
• Página de recursos do desenvolvedor do WebSphere Application Server
  Recursos técnicos para ajudá-lo a usar o WebSphere Application Server.
  
  
• Página do produto WebSphere Application Server
  Descrições e notícias sobre o produto, informações de treinamento e suporte etc.
  
  
• Centro de informações do WebSphere Application Server
  Um único portal da Web para toda a documentação do WebSphere Application Server, com informações conceituais, de tarefa e de referência sobre como instalar, configurar e usar o WebSphere Application Server.
  
  
• Roteiros de informações do WebSphere Application Server
  Roteiro de artigos e recursos para ajudá-lo com a instalação, a migração, a administração, a solução de problemas e a compreensão da tecnologia subjacente.
  
  
• Biblioteca de documentação do WebSphere Application Server
  Manuais de produto do WebSphere Application Server.
  
  
• Suporte para o WebSphere Application Server
  Um banco de dados pesquisável com problemas de suporte e suas soluções, além de downloads, correções, acompanhamento de problemas e muito mais.
  
  
• Recursos para o desenvolvedor do developerWorks WebSphere
  Informações técnicas e recursos para desenvolvedores que usam produtos WebSphere. O developerWorks WebSphere oferece downloads de produtos, informações de como proceder, recursos de suporte e uma biblioteca técnica gratuita de mais 2000 artigos técnicos, tutoriais, boas práticas, IBM Redbooks e manuais de produtos on-line.
  
  
• Recursos para o desenvolvedor de conectividade de aplicativo developerWorks WebSphere
  Artigos de como proceder, downloads, tutoriais, materiais de treinamento, informações sobre o produto e outros recursos para ajudá-lo a criar as soluções de conectividade de aplicativo e integração de negócios do WebSphere.
  
  
• Recursos do desenvolvedor de gerenciamento de processo de negócios do developerWorks WebSphere
  Artigos de como proceder, downloads, tutoriais, materiais de treinamento, informações sobre o produto e outros recursos do WebSphere BPM para ajudá-lo a montar, implementar e gerenciar os processos de negócios.
  
  
• Recursos do desenvolvedor de serviços Web e SOA do developerWorks WebSphere SOA
  Artigos de como proceder, downloads, tutoriais, materiais de treinamento, informações sobre o produto e outros recursos para ajudá-lo a projetar e criar soluções de serviços Web e SOA do WebSphere.
  
  
• Fóruns do WebSphere
  Fóruns específicos do produto em que é possível obter respostas para as suas perguntas técnicas e compartilhar o seu conhecimento com outros usuários do WebSphere.
  
  
• Blogs do developerWorks
  Participe de uma conversa com usuários e autores do developerWorks e desenvolvedores e editores da IBM.
  
  
• Podcasts do developerWorks
  Ouça entrevistas incomuns e interessantes e discussões com inovadores de software.
  
  
• developerWorks no Twitter Verifique as mensagens recentes no Twitter e os URLs.
  
  
• Most popular WebSphere trial downloads
  Download de avaliação grátis dos principais produtos do WebSphere.
  
  
• Downloads de teste para produtos de software IBM
  Downloads de teste gratuitos para produtos selecionados IBM® DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.
  
  
• Demonstrações WebSphere on-demand
  Transfira por download, assista e saiba o que os produtos WebSphere e tecnologias relacionadas ao WebSphere podem fazer por sua empresa.
  
  
• Eventos relacionados a WebSphere
  Conferências, feiras de negócios, Webcasts e outros eventos de interesse em todo o mundo para desenvolvedores WebSphere.
  
  
• Webcasts do developerWorks
  Sessões técnicas gratuitas oferecidas por especialistas da IBM que podem acelerar a sua curva de aprendizado e ajudá-lo a ter sucesso nos seus projetos de software mais difíceis. As sessões variam desde Webcasts de uma hora até sessões ao vivo de meio período ou de período integral nas cidades ao redor do mundo.
  
  
• Livros relacionados ao WebSphere da IBM Press
  Pedido on-line conveniente por meio da Barnes & Noble
  
  

Sobre os autores

Russell Butek é um consultor de SOA e de serviços Web para IBM Software Services for WebSphere e um dos desenvolvedores do mecanismos dos serviços Web para WebSphere. É membro do grupo de especialistas em AX-RPC Java Specification Request (JSR) e esteve envolvido na implementação do mecanismo Apache AXIS SOAP, impulsionando AXIS 1.0 para que fique em conformidade com JAX-RPC. Se precisar, entre em contato com Russell em butek@us.ibm.com.

John Rasmussen é um especialista sênior em TI na equipe do WebSphere DataPower SOA Appliance. Ele foi apresentado pela primeira vez aos dispositivos DataPower em 2001 enquanto trabalhava como engenheiro no setor de serviços financeiros desenvolvendo aplicativos XML/XSLT/JAXP para dispositivos móveis habilitados para Internet. John está na equipe de DataPower desde aquela época e trabalha como engenheiro de desenvolvimento de produtos e como especialista em produtos ajudando clientes a implementar as soluções de DataPower. Ele tem uma longa carreira em desenvolvimento de softwares, incluindo o trabalho com o software McCormack & Dodge/D&B e como consultor independente e desenvolvedor de aplicativos e sistemas de segurança. Se precisar, entre em contato com John em rasmussj@us.ibm.com.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Aplicativo de amostra
• Configurando o WebSphere Application Server
• Integrando WebSphere Application Server e DataPower -- o arquivo de chave LTPA
• Configuração do DataPower
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais