Introdução

Este artigo concentra-se nos aspectos relacionados à Federação de Identidade através das Arquiteturas Orientadas aos Serviços e em como apoiar este paradigma emergente utilizando o software® WebSphere.

A Federação de Identidade descreve casos de uso, padrões e tecnologias para possibilitar a propagação de informações de identidade através de diferentes domínios de segurança. Vários padrões são propostos para promover a federação entre empresas. Vamos nos concentrar principalmente na SAML e no WS-Security. Em termos de implementação de tecnologia, a Security Assertion Markup Language (SAML) é um padrão baseado em XML, desenvolvido pelo Comitê Técnico de Serviços de Segurança OASIS, com a finalidade de trocar dados de autenticação e autorização entre domínios de segurança, podendo, desta forma, ser utilizado para dar suporte à Federação de Identidade e realizar a propagação de identidade dentro de uma Empresa ou entre Empresas. Atualmente, a SAML está sendo adotada como veículo para propagar as informações de identidade através da Arquitetura Orientada aos Serviços.

Ao longo do artigo, mostraremos como o WebSphere Application Server e o Websphere DataPower podem atuar como um barramento de serviço corporativo em situações onde a Federação de Identidade se aplica. Nestas condições, casos de uso e exemplos provenientes de experiências reais fornecerão informações sobre como tratar das asserções da SAML com a capacidade proporcionada por esses dois produtos. O artigo está subdividido em seis partes:

1. Apresentação dos conceitos básicos relacionados ao paradigma da federação de identidade e à forma como a asserção de uma SAML é estruturada.
2. Descrição de um cenário de amostra em que ocorre a cooperação entre duas empresas, ilustrando a interação macro entre os usuários, as empresas e os aplicativos envolvidos.
3. Abordagem inicial para auxiliar nos aspectos de propagação de identidade utilizando as habilidades básicas do sistema de mensagens, introduzidas a partir da versão 6, do WebSphere Application Server.
4. Segunda abordagem para focar a mesma meta utilizando o WebSphere DataPower.
5. Demonstração do que ocorre no cenário de amostra.
6. Fatores referentes aos prós e contras de cada abordagem apresentada, levando-se em consideração principalmente os aspectos operacionais e de segurança antes da adoção em "ambiente real".

Principais elementos

• Federação de Identidade
• Security Assertion Markup Language (SAML)
• WS-Security
• habilidades básicas do serviço de mensagens do WebSphere Application Server
• WebSphere DataPower SOA Appliance

Este artigo pressupõe familiaridade com a tecnologia de Web Services e habilidade para desenvolver e implantar aplicativos J2EE, assim como familiaridade com os produtos WebSphere Application Server e WebSphere DataPower.

Voltar para parte superior

Federação de Identidade e SAML

O termo "Federação de Identidade" geralmente descreve casos de uso, padrões e tecnologias capazes de possibilitar a propagação das informações de identidade através de diferentes domínios de segurança. Esta portabilidade de identidade é alcançada principalmente com base em padrões abertos. O objetivo é oferecer especificações e padrões abertos, capazes de fornecer um espectro amplo de casos de uso e interoperabilidade. A Federação de Identidade visa capacitar os usuários de um domínio a acessar, de forma segura, aplicativos, dados ou serviços de outros domínios continuamente, sem a necessidade de autenticação e administração de outro usuário. Os casos de uso típicos incluem, por exemplo, SSO entre domínios web, troca de atributo de usuário entre domínios, cooperação de aplicativos entre domínios. A adoção do paradigma da Federação de Identidade e seus padrões poderiam promover diversas vantagens como:

• Redução de custos através do aumento da economia de escala reutilizando os serviços existentes
• Menos redundância de dados
• Maior segurança e menor risco permitindo que a empresa identifique e autentique um usuário uma vez e então utilize essas informações de identificação em vários sistemas, inclusive em parceiros externos
• Aprimoramento da privacidade permitindo que o usuário controle quais informações são compartilhadas e limitando a quantidade de informações compartilhadas com outros parceiros
• Melhores condições para o usuário final eliminando a necessidade de cadastrar novas contas através do "fornecimento associado" automático ou evitando login redundante através de uma conexão entre domínios

A Federação de Identidade pode ser executada de diversas formas, sendo que algumas delas envolvem a utilização dos padrões formais de Internet como a especificação OASIS Security Assertion Markup Language (SAML) e algumas propostas de software livre como Cartões de Informação, OpenID e a estrutura de confiança Higgins. A OASIS Security Assertion MarkUp Language fornece linguagem de marcações para representar asserções de segurança.

Tais asserções são criadas pela entidade responsável pelo cumprimento da segurança (como um serviço de segurança) para transmitir suas constatações a outras entidades que dependem dessas constatações. A SAML, desenvolvida pelo Comitê Técnico de Serviços de Segurança da Organização para o Avanço dos Padrões de Informações Estruturadas (OASIS), é uma estrutura baseada em XML para comunicar a autenticação e autorização do usuário, e as informações de atributo. Como o nome sugere, a SAML permite que as entidades de negócios façam asserções com relação à identidade, aos atributos e às autorizações de um assunto (uma entidade que frequentemente é uma pessoa) para outras entidades, como empresas parceiras ou outros aplicativos corporativos. Tais informações são transmitidas através da troca de asserções entre as partes que emitem as asserções e a parte que recebe as asserções com a finalidade de autenticá-las e autorizá-las). A especificação da SAML é organizada com uma abordagem modular e baseia-se em alguns blocos de construção que serão apresentados resumidamente a seguir (consulte a seção de Recursos para obter mais informações sobre a SAML).

Asserções

Como já mencionado, asserções carregam instruções sobre um principal que uma parte assertiva declara ser verdadeiro, em que a estrutura válida e o conteúdo de uma asserção são definidos pelo esquema XML de asserção SAML. As asserções normalmente são criadas por uma parte assertiva (também conhecida como provedor de identidade ou IdP) com base em uma solicitação de algum tipo de uma parte dependente (também conhecida como provedor de serviço ou SP), e contêm instruções que provedores de serviço usam para tomar decisões de controle de acesso. Três tipos de instruções são fornecidos pela SAML:

• Instruções de autenticação
• Instruções de atributo
• Instruções de decisão de autorização

As instruções de autenticação declaram ao provedor de serviço que o principal certamente se autenticou no provedor de identidade em um dado momento, usando um método bem definido de autenticação. Outras informações sobre o método de autenticação usado pelo principal (chamado contexto de autenticação) podem ser incluídas em uma instrução de autenticação.

Uma instrução de atributo declara que um assunto está associado a certos atributos. Um atributo é simplesmente um par nome-valor. Partes dependentes usam atributos para tomar decisões de controle de acesso de baixa granularidade.

Uma instrução de decisão de autorização declara que um sujeito está autorizado a realizar a ação “A” no recurso “R” dada a evidência “E”.

Protocolos

Os protocolos descrevem como as asserções são empacotadas na solicitação SAML e elementos de resposta. Correspondendo aos três tipos de instrução, há três tipos de consulta SAML:

• Consulta de autenticação
• Consulta de atributo
• Consulta de decisão de autorização

Ligações

Ligações são um mapeamento de uma mensagem de protocolo SAML em formatos de sistema de mensagens padrão e/ou protocolos de comunicação. Por exemplo, a ligação SOAP SAML especifica como uma mensagem SAML é encapsulada em um envelope SOAP, sendo ele mesmo ligado a uma mensagem HTTP.

Perfis

Perfis descrevem em detalhes como as asserções, protocolos e ligações SAML se combinam para suportar um caso de uso definido.

Voltar para parte superior

Um cenário de amostra

Vamos supor um cenário de amostra relativo a uma cooperação de aplicativos entre dois parceiros hipotéticos (JHKL Inc. e ACME Inc.). O cenário introduzido se baseará nas seguintes suposições:

• A JHKL Inc. torna um serviço disponível à ACME Inc.
• A tecnologia de serviço da Web é usada para implementar as relações aplicativo a aplicativo
• A SAML é usada para permitir a propagação de identidade entre as duas empresas

Supomos que as duas empresas escolheram usar o mesmo padrão, implementando um Gateway de barramento de serviço corporativo (doravante simplesmente ESB Gateway) especializado para sustentar a cooperação de aplicativos junto a parceiros externos. Dessa forma, o "Aplicativo A" (assim como outros possíveis aplicativos internos) não precisa mudar sua abordagem natural para assegurar aspectos como propagação de identidade, já que o Gateway do barramento de serviço corporativo lidará com todas as mensagens direcionadas ao "Aplicativo B", adaptando-as às regras de federação de identidade estabelecidas com a JHKL Inc.

As seções a seguir mostram como as duas empresas realizam seu próprio ESB Gateway usando uma abordagem diferente.

O que acontece quando John Doe tenta acessar o "Aplicativo B"

John Doe é funcionário da ACME Inc. e está trabalhando no "Aplicativo A", assim como em outros aplicativos internos. Ele já realizou uma autenticação e naturalmente sua credencial possui apenas validade e significado locais. Quando John Doe dispara uma solicitação onde o "Aplicativo A" precisa interagir com o "Aplicativo B", o "Aplicativo A" envia as mensagens para o ESB Gateway responsável por realizar todas as tarefas necessárias e a transformação do protocolo de segurança. Na verdade, estamos pressupondo aqui que o "Aplicativo A" pertence a um domínio particular onde a ACME Inc. escolheu o Token do nome de usuário WS-Security (doravante simplesmente WS-UNT) como um veículo comum para possibilitar a propagação de identidade, então o "Aplicativo A" envia normalmente as mensagens contendo uma credencial de usuário local encapsulada em um WS-UNT. A função do ESB Gateway é transformar este tipo de credencial em algo compreensível para a JHKL Inc. Para isso, o ESB Gateway:

1. Valida e extrai do WS-UNT a identidade do usuário (por exemplo: "John Doe")
2. Remove o WS-UNT
3. Acrescenta a Asserção de Autenticação SAML (encapsulada em um cabeçalho WS-Security) contendo:
   • A identidade do usuário (por exemplo: "John Doe")
   • Atributos que declaram as funções da identidade do usuário (por exemplo: "Convidado")
   • Uma assinatura digital que assegura a integridade da mensagem como a identidade do provedor
4. Encaminha a mensagem para o "Aplicativo B"

É importante observar como o atributo que declara a função do usuário (por exemplo: "Convidado") deve ser baseado em uma nomenclatura estabelecida entre a ACME Inc. e a JHKL Inc. durante o acordo comercial.

O que ocorre dentro da JHKL Inc.

Ainda sob a perspectiva da ACME Inc., não pressupomos aqui detalhes tecnológicos sobre a implementação do Sistema de Informações do parceiro, mas a nossa atenção concentra-se apenas em qual informação a JHKL Inc. tem de tratar, dada uma Asserção de Autenticação SAML. Nessas condições, dada uma Asserção SAML, a JHKL Inc. deve:

1. Validar a assinatura digital para garantir a origem e a integridade da mensagem
2. Extrair a identidade do responsável pela chamada (por exemplo, "John Doe") e falsificar uma identidade transitória local, especialmente para fins de auditoria (quem fez o que)
3. Extrair a função do responsável pela chamada do atributo de asserção (por exemplo: "Convidado"), para atribuir um nível de autorização para o responsável pela chamada

Sobre o último ponto, a JHKL Inc. também poderia atribuir uma identidade local válida de "serviço" para o responsável pela chamada com base em sua função (por exemplo, "Convidado"), para focar os requisitos de propagação de identidade interna se, por exemplo, o "Aplicativo B" exige que se aplique um processo de autorização e/ou o acesso a outros recursos assegurados. Para focar a propagação interna de identidade, beneficiando-se da Federação de Identidade, a HKL Inc não precisa mapear internamente as identidades da ACME Inc., mas pode estabelecer uma relação "m:n" onde:

• "m" é o número de todas as funções possíveis estabelecidas entre a JHKL Inc. e a ACME Inc.
• "n" é número de todos os diferentes níveis possíveis de autorização, cada um associado a uma identidade de serviço localmente válida

Voltar para parte superior

Uma abordagem para realizar o ESB Gateway da ACME Inc.

A ACME Inc. opta por implementar o ESB Gateway usando essencialmente as habilidades básicas do WebSphere Application Server, como os recursos de serviço de mensagens introduzidos na versão 6. Entretanto, além do produto WebSphere Application Server, a ACME Inc. precisou desenvolver dois componentes de software para manter a arquitetura, detalhadamente:

• Um aplicativo customizado (que inclui o projeto de software livre OpenSAML) que atua como um Provedor de Asserção SAML.
• Um manipulador JAX-RPC que invoca o Provedor SAML da camada ESB

Olhando o diagrama acima, acompanhe o que acontece quando o "Aplicativo A" tenta invocar o serviço exibido pela JHKL Inc.

1. O "Aplicativo A" envia uma mensagem de solicitação SOAP contendo um WS-UNT
2. O Ouvinte SOAP Http aceita a mensagem e a encaminha para o componente do Serviço de Entrada
3. O WS-UNT é validado e removido da mensagem, mas um sujeito de segurança (identidade de usuário) assume a posição
4. O Serviço de Entrada encaminha a mensagem para o componente do Serviço de Saída
5. O manipulador JAX-RPC adiciona uma Asserção de Autenticação SAML (desenvolvida também na identidade do usuário) na mensagem executando o aplicativo do Provedor the SAML
6. O componente do Serviço de Saída encaminha a mensagem para o "Aplicativo B"

Implementação do ESB Gateway da "Empresa A"

O ESB Gateway para a "Empresa A" se apoia essencialmente no Barramento de Integração de Serviços (SIB), um recurso introduzido pelo WebSphere Application Server V6. Para realizar a arquitetura descrita na Figura 2, as seguintes etapas principais são necessárias:

1. Instale o manipulador JAX-RPC e o aplicativo do Provedor SAML
2. Habilite o WebSphere Application Server para o repositório dos Objetos de Dados de Serviço
3. Configuração de um ouvinte SOAP/HTTP no servidor do aplicativo associado ao BUS
4. Criação de um BUS, como os serviços de entrada e saída
5. Defina as configurações do Web Service WS-Security, providencie a ligação para as mensagens de entrada e anexe-as à porta de serviços de entrada
6. Defina a lista do manipulador X-RPC e anexe-a à porta de serviços de saída

A finalidade desta seção não é servir de guia passo a passo para desenvolver a arquitetura desejada, pois todas as informações detalhadas de cada etapa podem ser encontradas na seção de Recursos. De qualquer forma, os parágrafos a seguir fornecem uma breve descrição dos principais elementos que realizam o ESB Gateway da ACME Inc., oferecendo mais detalhes sobre os aspectos específicos deste cenário de amostra (o manipulador JAX-RPC, o aplicativo customizado STS, a configuração e ligação do serviço da web ws-security).

O repositório de Objetos de Dados de Serviço

Objeto de Dados de Serviços (SDO) é um padrão aberto para habilitar aplicativos a gerenciar dados de diferentes origens de maneira uniforme, como gráficos de dados. Por exemplo, o SIB utiliza o repositório SDO para armazenar e apresentar as definições WSDL, como o modelo de programação de mediação que oferece uma interface SDO para todas as mensagens e uma API comum para acessar propriedades e metadados.

Habilitar o WebSphere Application Server para o SDO é simples e, considerando o ambiente de teste onde utilizamos o perfil independente do WebSphere Application Server, executamos apenas os seguintes comandos:

1. Abra uma janela de comando
2. Mude para <WAS_HOME>/diretório bin
3. Execute o comando: wsadmin -f installSdoRepository.jacl -createDb node1 server1"

Os comandos acima instalam um repositório SDO utilizando o banco de dados IBM Cloudscape®. No final do procedimento, no console de administração do WebSphere, deve aparecer um novo aplicativo denominado Repositório SDO.

Integração de Serviços BUS e Ouvinte SOAP/HTTP

O WebSphere Application Server V6 apresenta um mecanismo de serviço de mensagens completamente novo, desenvolvido em Java™ . As informações detalhadas sobre este recurso podem ser obtidas na seção Recursos. Entretanto, podemos definir aqui o Barramento de Integração de Serviços (doravante simplesmente BUS) como uma nuvem lógica que oferece os mecanismos para interligar consumidores e fornecedores. Esta nuvem lógica contém:

• Mecanismo do sistema de mensagens. um componente hospedado pelo WebSphere Application Server (uma única instância ou cluster) capacitado para transmitir mensagens aos destinos
• Destino: um terminal lógico no qual os aplicativos podem se conectar como produtores, consumidores (ou ambos)
• Ponto de mensagem: um local hospedado pelos mecanismos de serviços de mensagens onde as mensagens são mantidas para envio a um destino

Para realizar o cenário de amostra da Figura 3, utilizamos instâncias únicas de amostra do WebSphere Application Server para o qual configuramos um BUS que tem:

• O exclusivo Websphere Application Server independente como membro
• The Mecanismo de serviços de mensagens hospedado pelo WebSphere Application Server independente
• Uma "fila" de Destino para o Serviço de Entrada
• Um tipo de "Serviço da Web" de Destino para o Serviço de Saída
• Uma associação com o ouvinte SOAP/HTTP hospeda a instância do WebSphere Application Server independente como membro

O ouvinte SOAP/HTTP providencia a forma de um serviço no BUS ser executado, então, no cenário de amostra, representa o ponto de extremidade alvo para o "Aplicativo A", quando este último aciona o acesso ao "Aplicativo B".

Detalhadamente, o URI exibido pelo ESB Gateway segue a estrutura: [prefixo do listener SOAP HTTP/mecanismosoaphttp/nome do barramento]/[nome do Serviço de Entrada]/[nome da Porta do Serviço de Entrada]

Configuração e ligação do WS-Security

O ESB Gateway precisa adotar uma política de segurança para aceitar somente mensagens SOAP novas que contenham uma identidade localmente válida. Para cumprir esses requisitos, as ligações e configurações do WS-Security podem ser definidas e anexadas à porta de serviço de entrada do Bus. As informações sobre como realizar essa etapa podem ser encontradas na seção de Recursos), porém as tabelas a seguir mostram os principais parâmetros usados para definir as ligações e configurações do WS-Security para um WS-UNT.

No console de administração do WebSphere, a configuração e a ligação do WS-Security devem ser definidas no menu de Integração de Serviços, conforme demonstra a figura abaixo.

Sucessivamente, a configuração e a ligação do WS-Security devem ser conectadas à porta de Serviço de Entrada, conforme demonstra a figura abaixo.

Manipulador JAX-RPC

Em nossa situação, o manipulador JAX-RPC opera no tráfego recebido (do "Aplicativo A"), adotando uma transformação de mensagem capaz de inserir uma Asserção de Autenticação SAML nas novas mensagens.

O manipulador obtém uma Asserção SAML válida e assinada invocando o aplicativo do Provedor SAML customizado.

public boolean handleRequest(MessageContext context)
{
   try
   {
      log(Level.INFO,"handleRequest","Start to handle a SOAP Request");
      SOAPMessageContext soapMsgCtx=(SOAPMessageContext)context;
      SOAPMessage soapMessage=soapMsgCtx.getMessage();

      ByteArrayOutputStream xml=new ByteArrayOutputStream();
      soapMessage.writeTo(xml);
      String message=xml.toString();
      log(Level.FINEST,"handleRequest","Message to handle: "+message);

      String subject=WSSubject.getCallerPrincipal();
      if (subject==null)
      {
         log(Level.INFO,"handleRequest","Missing subject");
         return false;
      }
      log(Level.INFO,"handleRequest","Identity found: "+subject);

      Context ctx=new InitialContext();
      STSEngineHome home=(STSEngineHome)ctx.lookup(STS_EJB);
      STSEngine stsEngine=home.create();

      String newMessage=stsEngine.doMessageTransformation(message, subject);

      log(Level.FINEST,"handleRequest","Message produced: "+newMessage);
      soapMsgCtx.setMessage(getSOAPMessage(newMessage));

      return true;
   } catch (Exception e)
   {
      log(Level.INFO,"init","blocking error: "+e.getMessage());
      e.printStackTrace();
      return false;
   }
}

Olhando a fonte da Listagem 1, as linhas em negrito indicam os pontos em que o manipulador:

1. Obtém a identidade do usuário da camada WebSphere, como resultado da criação de um assunto depois que se adota a política WS-Security
2. Invoca-se o aplicativo do Provedor SAML (via RMI-IIOP), fornecendo tanto a mensagem como a identidade para obter uma nova mensagem contendo a Asserção de Autenticação assinada SAML.

Aplicativo do Provedor de SAML

De forma bem sintetizada, o aplicativo do Provedor de SAML disponibiliza a função:

O aplicativo solicita uma mensagem e uma identidade, e então retorna uma nova mensagem contendo a Asserção de Autenticação SAML. O Provedor SAML é um Aplicativo Corporativo que contém um módulo Enterprise Java Bean, já que a função de transformação é implementada por uma Sessão de Enterprise Java Bean (a fonte na Listagem 2 mostra a interface remota), este último conta com o projeto OpenSAML para produzir Asserções SAML assinadas.

package com.ibm.customsts.ejbs;

/**
 * Remote interface for Enterprise Bean: STSEngine
 */
public interface STSEngine extends javax.ejb.EJBObject {

public String doMessageTransformation(String message,String subject)
throws Exception;
}

Considerando a produção de Asserções, esta atividade tem implicações importantes, com relação à governança, gerenciamento de sistemas, implementações e assim por diante, como:

• Gerenciamento de certificados digitais exigidos para a assinatura digital
• Capacidade de atribuir uma função para uma determinada identidade

Em se tratando do gerenciamento de informações relacionadas ao mapeamento entre identidades locais e funções estabelecidas com a JHKL Inc., em nossa situação, o aplicativo do Provedor da SAML está simplesmente desprovido deste aspecto, já que sempre atribui a mesma função para todas as identidades determinadas. Obviamente, esta opção não se aplica a ambientes reais de produção. O LDAP e os produtos de Gerenciamento de Identidade representam um bom ponto para armazenar informações sobre o mapeamento entre identidades e funções, e uma maneira simples de gerenciar essas correlações de informações, mas aplicativos customizados como o Provedor da SAML devem ser adaptados a eles.

Começando pelo cenário de amostra, mas pensando em um ambiente real de produção, a implementação de um Serviço de Token de Segurança (doravante, simplesmente STS) poderia representar a forma correta de suportar uma Federação de Identidade, obtendo mais flexibilidade e eficiência.

Em um ecossistema de serviços da Web, um STS implementa uma interface WS-Trust e emite, troca e valida tokens de segurança, atuando como um terceiro de confiança para as relações de confiança do broker entre consumidor e provedor. O padrão aberto do WS-Trust define como solicitar e emitir tokens de segurança e como estabelecer uma relação de confiança.

Embora o WebSphere Application Server possa contatar o Serviço de Token de Segurança diretamente, a Figura 6 mostra como o cenário de amostra poderia ficar após a introdução do componente STS, onde o ESB manteria o gerenciamento da transformação do protocolo de segurança. Porém, o STS seria completamente responsável por construir e fornecer asserções SAML, beneficiando-se de sua integração com os componentes de Gerenciamento de Identidade.

Voltar para parte superior

O ESB Gateway da JHKL Inc.

Nesta seção, conforme demonstrado na Figura 7, a JHKL Inc. opta por realizar o ESB Gateway utilizando o WebSphere DataPower SOA Appliance.

Neste caso, o WebSphere DataPower é responsável por:

1. Validar a assinatura digital da Asserção da SAML
2. Associar uma identidade de serviço localmente válida para a função do responsável pela chamada
3. Trocar a Asserção da SAML para um diferente protocolo de segurança, capaz de realizar a identidade de serviço

Com relação aos pontos 2 e 3, pressupondo que o próprio WebSphere DataPower precise solucionar esses aspectos, seguindo os métodos escolhidos para a nossa situação:

1. Utilize um arquivo XSL simples para mapear as funções da SAML em identidades de serviço localmente válidas
2. Gere um Token LTPA no nível de transporte para habilitar a propagação de identidade

Na seção anterior, pressupomos que a ACME Inc utiliza o WS-UNT para habilitar a propagação de identidade dentro do domínio particular, opção que representa um dos métodos mais comuns interoperáveis. Em contrapartida, pressupomos que a JHKL Inc. se beneficie da utilização do token LTPA, que é um protocolo proprietário. A opção da JHKL Inc. conta com a premissa de que, considerando uma infraestrutura geral de Arquitetura Orientada a Serviços, nem sempre a completa interoperabilidade se faz necessária.

Pressupondo que o "Aplicativo B" sempre será compatível com o LTPA e será solicitado por um número crescente de consumidores, como a necessidade de acessar outros recursos internos e seguros (como o Enteprise Java Beans) com as células do WebSphere, o token do LTPA poderia ser uma escolha lógica, graças às suas características de gerenciamento e desempenho. Na verdade, a propagação de uma identidade de ponta a ponta que conta com a geração de token de segurança para cada hop envolvido pode sair caro. O token LTPA representa uma maneira segura de propagar uma identidade, pois é criptografado, assinado e oferece um recurso para definir período de validade.

Implementando o ESB Gateway da JHKL Inc.

Para implementar o ESB gateway da JHKL Inc.,um objeto WS-Proxy foi configurado dentro do DataPower e, conforme demonstrado na Figura 5, o nosso fluxo de solicitação contém basicamente duas ações:

1. Uma ação de validação
2. Uma ação AAA

Enquanto a ação de validação somente verifica a assinatura de Asserção da SAML, a ação AAA executa um trabalho mais complexo.

A configuração do AAA

Em uma primeira etapa, o AAA precisa extrair a identidade do usuário e essa é uma tarefa importante dentro do cenário de amostra. Na realidade, os assuntos de asserção contêm a identidade do responsável pela chamada (por exemplo, "Jhon Doe"), mas da perspectiva da JHKL Inc., esta informação poderia ser útil para as ações de auditoria. Em vez disso, precisamos extrair a função do responsável pela chamada para o processo de autenticação e propagação de identidade (por exemplo, "Convidado"), já que sob a perspectiva da Federação de Identidade, esta informação é destinada à JHKL Inc. e pode ser mapeada para a identidade de serviço local. Por essa razão, conforme demonstrado na Figura 9, utilizamos uma expressão XPATH para extrair a função do responsável pela chamada do atributo de Asserção da SAML.

A esta altura, precisamos somente trocar a função do responsável pela chamada por uma identidade de serviço local e utilizamos um arquivo de informação AAA para fazer isso.

A figura abaixo mostra o arquivo de informação AAA usado para mapear funções para identidades de serviço locais. Apenas com a finalidade de testar, o arquivo de informação AAA contém somente uma relação onde a função de "Convidado" é mapeada para a identidade "iod=service1,o=defaultWIMFileBasedRealm", mas este arquivo mostra como é o mapeamento somente entre um número restrito de itens (todas as possíveis funções) e um número restrito de identidades locais (uma para cada nível de autorização). Utilizamos um arquivo de informação AAA, mas o DataPower permite uma grande flexibilidade e é possível lidar com este mapeamento de outras maneiras, por exemplo, consultando um LDAP.

<?xml version="1.0" encoding="utf-8"?>
<AAAInfo xmlns="http://www.DataPower.com/AAAInfo">
  <FormatVersion>1</FormatVersion>
  <Summary>Map abstract role to local service identity.</Summary>
  <MapCredentials>
    <InputCredential>Guest</InputCredential>
    <OutputCredential>uid=service1,o=defaultWIMFileBasedRealm</OutputCredential>
  </MapCredentials>
</AAAInfo>

Com esta etapa, queremos apenas autorizar todas as solicitações autenticadas, isto é, todas as solicitações com assinatura e função válidas (onde uma função é válida se o arquivo de informação AAA puder mapeá-la para uma identidade local).

A última etapa implementa a transformação da mensagem. Aqui, removemos o cabeçalho do WS-Security e geramos um token LTPA (no nível de transporte) desenvolvido na identidade mapeada (a função "Convidado").

Voltar para parte superior

Teste o cenário de amostra

Para o nosso teste, com o intuito de simular o "Aplicativo B", nós desenvolvemos um Servidor da Web simples que exibe uma operação para ter os dados atuais, em vez de usarmos uma ferramenta genérica do cliente de Serviço da Web para estimular o "Aplicativo A".

A listagem 5 mostra uma mensagem de solicitação do "Aplicativo A", onde é possível ver o WS-UNT (contendo a identidade de John Doe) dentro do Cabeçalho SOAP.

<soapenv:Envelope 
xmlns:log="http://logic.echoservice.la41318.it/"
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<soapenv:Header>
 <wsse:Security soapenv:mustUnderstand="1" 
   xmlns:wsse="http://.../oasis-200401-wss-wssecurity-secext-1.0.xsd">
      <wsse:UsernameToken wsu:Id="UsernameToken-624174388" 
      xmlns:wsu="http://.../oasis-200401-wss-wssecurity-utility-1.0.xsd">
	
         <wsse:Username>john.doe</wsse:Username>
         <wsse:Password Type="http://...wss-username-token-profile-1.0#PasswordText">
            passw0rd
         </wsse:Password>
	
         </wsse:UsernameToken>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <log:getDate/>
   </soapenv:Body>
</soapenv:Envelope>

Observando a mensagem produzida pelo ESB Gateway da ACME Inc. (Listagem 5), nosso foco está em três filhos da Asserção da SAML:

• O emissor indica a ACME Inc. como proprietária da Asserção
• O assunto indica John Doe como a identidade responsável pela chamada
• O enunciado do atributo indica que John Doe obteve a função de "Convidado"

<soapenv:Envelope  xmlns:log=".../" xmlns:soapenv="..." xmlns:env="..." xmlns:dp="...">
   <soapenv:Header>
      <wsse:Security xmlns:wsse="..." soapenv:mustUnderstand="1">
         <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
         ID="1" IssueInstant="2010-01-19T15:34:33.331Z" Version="2.0">
	
            <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
               ACME Inc.
            </saml:Issuer>
	
            <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
               /..../
            </ds:Signature>
	
            <saml:Subject>
              <saml:NameID>john.doe</saml:NameID>
                 <saml:SubjectConfirmation>
                    <saml:SubjectConfirmationData 
                         Address="urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"/>
                 </saml:SubjectConfirmation>
           </saml:Subject>
	
           <saml:Conditions 
                 NotBefore="2010-01-18T15:34:33.331Z" 
                 NotOnOrAfter="2010-01-20T15:34:33.331Z"/>
	
           <saml:AttributeStatement>
             <saml:Attribute Name="Role" NameFormat="Role">
                <saml:AttributeValue xmlns:xsi="..." xmlns:xs="..." 
                        xsi:type="xs:string">
                   Guest
                </saml:AttributeValue>
             </saml:Attribute>
           </saml:AttributeStatement>
	
           <saml:AuthnStatement AuthnInstant="2010-01-19T15:34:33.331Z">
             <saml:AuthnContext>
               <saml:AuthnContextClassRef>
                     urn:oasis:names:tc:SAML:2.0:ac:classes:Password
               </saml:AuthnContextClassRef>
             </saml:AuthnContext>
            </saml:AuthnStatement>
         </saml:Assertion>
      </wsse:Security>
   </soapenv:Header>
   <soapenv:Body>
      <log:getDate/>
   </soapenv:Body>
</soapenv:Envelope>

Pressupomos que o ESB Gateway da JHKL Inc. propaga a identidade para o "Aplicativo B" utilizando o token LTPA no nível de transporte, por esta razão, conforme demonstrado na Listagem 7, a mensagem de solicitação produzida pelo DataPower não contém nenhuma informação de WS-Security.

<soapenv:Envelope xmlns:soapenv="..." xmlns:env="..." xmlns:dp="...">
   <soapenv:Header>
   </soapenv:Header>
   <soapenv:Body>
      <log:getDate/>
   </soapenv:Body>
</soapenv:Envelope>

Em vez disso, a figura 13 exibe informações sobre a solicitação de mensagem que o DataPower encaminhou ao "Aplicativo B", onde é possível ver o cookie LTPA adicionado através da ação pós-processamento (Figura 12).

No final, a listagem 8 exibe a mensagem de resposta do"Aplicativo B".

Em nosso cenário de amostra, pressupomos que nenhuma informação de segurança é necessária na direção da resposta, mas em um ambiente de produção, a ACME Inc. poderia exigir uma mensagem de resposta assinada para se certificar da integridade e da origem da mensagem.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
   <soapenv:Body>
      <ns2:getDateResponse xmlns:ns2="http://logic.echoservice.la41318.it/">
         <return>[Tue Jan 19 16:34:33 CET 2010]</return>
      </ns2:getDateResponse>
   </soapenv:Body>
</soapenv:Envelope>

Voltar para parte superior

Conclusão

Este artigo parte da necessidade de dar suporte à Federação de Identidade entre as empresas (ou dentro de uma única empresa) e utiliza um cenário de cooperação de aplicativos de amostra para propor duas possíveis soluções. Ambas as soluções pressupõem que o gateway do barramento de serviço corporativo seja utilizado como padrão de implementação, uma vez que representa um bloco de construção para focar de maneira harmoniosa esses cenários de cooperação, evitando impactos significativos na infraestrutura de TI existente e no comportamento usual do aplicativo interno

Devido a essa suposição, duas possíveis soluções para implementar um ESB Gateway foram introduzidas, a primeira alavanca as funções básicas do Websphere Application Server ao passo que a segunda alavanca os recursos integrados do DataPower. O que deveria ficar claro ao ler o artigo são as dificuldades que podem surgir durante a implementação dos cenários descritos e como isso poderia ser solucionado, usando diferentes estratégias de implementação.

Como se pode imaginar em um cenário em grande escala, a solução de melhor desempenho, mais robusta e ainda assim flexível, seria aquela composta pelo ESB juntamente com o Serviço de Token de Segurança (STS). Este serviço de broker emite e valida os tokens de segurança, atuando como uma autoridade de confiança que separa o serviço de autenticação da infraestrutura ESB.

Voltar para parte superior

Downloads

Informações sobre métodos de download

Recursos

• "Comunidade Oficial da SAML": Obtenha informações sobre o produto.
  
  
• "OpenSAML home page": Obtenha informações sobre o produto.
  
  
• "Uma introdução prática da mediação de mensagem": Obtenha informações detalhadas sobre mediação de mensagens, um novo recurso introduzido pelo WebSphere Application Server V6.
  
  
• "Centros de Informações do WebSphere Application Server": Obtenha a documentação do produto.
  
  
• "Construindo um Barramento de Serviço Corporativo com o WebSphere Application Server V6 " Uma série de artigos sobre como alavancar os recursos do WebSphere Application Server para focar os aspectos de integração. Especialmente as partes 5 e 7 contêm informações detalhadas sobre como desenvolver a arquitetura proposta neste artigo.
  
  
• "Padrão WS-Trust": Introdução e especificação WS-Trust do OASIS.
  
  

Sobre os autores

Andrea Carmignani é arquiteto senior de TI e trabalha para a IBM desde 2007. Ele atua como arquiteto e consultor de TI focando principalmente nas questões de segurança relacionadas à arquitetura da empresa, computação em nuvem, virtualização e às infraestruturas S.O.A, assim como os temas tradicionais de segurança como Privacidade, Auditoria e Gerenciamento de Identidade. Geralmente, ele é responsável pela definição das soluções de ponta a ponta, em termos de arquitetura, produtos e processos organizacionais para abordar os aspectos de segurança e privacidade. Suas obrigações variam dentre diversos segmentos como a Telco, Governo e Finanças Públicas, abrangendo clientes nacionais e europeus. Anteriormente, fez parte do departamento de Segurança e Fraudes de TI de uma grande empresa italiana da Telco.

Angelo Littera é arquiteto senior de TI para a IBM Global Technology Services na Itália. Ele ingressou na IBM em 1996. Como especialista em TI, trabalhou em muitos projetos para clientes de diversos segmentos, atuando como SME nas plataformas Unix (AIX/Linux), mas principalmente nas tecnologias Java e nos produtos WebSphere. Como arquiteto de TI, novo é responsável pela definição de soluções arquitetônicas de infraestrutura, focando a Arquitetura Orientada aos Serviços, as tecnologias de serviços da Web e as tecnologias Java Enterprise. Nos últimos anos, participou de diversos projetos, empenhando-se na criação de soluções para enfocar a necessidade de integração de serviços na Administração Pública da Itália. Ele sempre publica documentos na IBM Intellectual Capital Management.

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Federação de Identidade e SAML
• Um cenário de amostra
• Uma abordagem para realizar o ESB Gateway da ACME Inc.
• O ESB Gateway da JHKL Inc.
• Teste o cenário de amostra
• Conclusão
• Downloads
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

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

---

Saiba mais