Mapeamentos de Login

Mapeamentos de login, encontrados no arquivo XML (Extended Markup Language) ibm-webservices-bnd.xmi, contêm uma configuração de mapeamento. Essa configuração de mapeamento define como o manipulador de segurança dos Serviços da Web mapeia o elemento <ValueType> do token que está contido no token de segurança extraído do cabeçalho da mensagem, para o método de autenticação correspondente. O elemento <ValueType> do token está contido dentro do token de segurança extraído de um cabeçalho de mensagem SOAP.

Importante: Há uma distinção importante entre aplicativos da Versão 5.x e Versão 6 e posterior. As informações suportam somente aplicativos Versão 5.x que são usados com o WebSphere Application Server Versão 6.0.x e posterior. As informações não se aplicam aos aplicativos da Versão 6 e posterior.

O manipulador de segurança dos Serviços da Web do lado do emissor gera e anexa tokens de segurança baseados no elemento <AuthMethods> que está especificado no descritor de implementação. Por exemplo, se o método de autenticação for BasicAuth, a rotina de tratamento de segurança do emissor gera e conecta UsernameToken (com o nome do usuário e a senha) ao cabeçalho da mensagem SOAP. O tempo de execução de segurança dos serviços da Web utiliza a interface javax.security.auth.callback.CallbackHandler do Java™ Authentication and Authorization Service (JAAS) como um provedor de segurança para gerar tokens de segurança no lado do cliente (ou quando os serviços da Web estão atuando como cliente).

O manipulador de segurança do emissor chama o método handle() de uma implementação da interface javax.security.auth.callback.CallbackHandler. Essa implementação cria o token de segurança e transmite o token de volta à rotina de tratamento de segurança do emissor. A rotina de tratamento de segurança do emissor constrói o token de segurança com base nas informações de autenticação na matriz de retorno de chamada. Em seguida, a rotina de tratamento de segurança insere o token de segurança no cabeçalho da mensagem de Segurança de Serviços da Web.

A implementação da interface do CallbackHandler que você utiliza para gerar o token de segurança necessário está definida no elemento <loginBinding> no arquivo de ligação da Segurança dos Serviços da Web ibm-webservicesclient-bnd.xmi. Por exemplo,
<loginBinding xmi:id="LoginBinding_1052760331526" authMethod="BasicAuth"
      callbackHandler="com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler"/>
O elemento <loginBinding> associa a interface com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler ao método de autenticação BasicAuth. O WebSphere Application Server fornece o seguinte conjunto de implementações da interface CallbackHandler que é possível utilizar para criar vários tipos de tokens de segurança:
com.ibm.wsspi.wssecurity.auth.callback.GUIPromptCallbackHandler
Se não houver dados de autenticação básica definidos nas informações de ligação de login (estas informações não são as mesmas que as informações de autenticação básica HTTP), o tipo de token anterior pede o nome do usuário e a senha através de um painel de login. A implementação utiliza os dados de autenticação básica definidos na ligação de login. Utilize esse CallbackHandler com o método de autenticação BasicAuth. Não utilize essa implementação CallbackHandler no servidor, pois ela solicita informações sobre ligação de login.
com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler
Se os dados de autenticação básica não estiverem definidos nas informações de ligação de login (estas informações não são as mesmas que as informações de autenticação básica HTTP), a implementação pede o nome do usuário e senha utilizando a entrada padrão (stdin). A implementação utiliza os dados de autenticação básica definidos na ligação de login. Utilize essa implementação CallbackHandler com o método de autenticação BasicAuth. Não utilize essa implementação CallbackHandler no servidor, pois ela solicita informações sobre ligação de login.
Restrição: Se você tiver um cliente multiencadeado e múltiplos encadeamentos tentarem ler a partir do padrão ao mesmo tempo, todos os encadeamentos falharão em obter as informações de nome e senha do usuário. Portanto, não é possível usar a implementação com.ibm.wsspi.wssecurity.auth.callback.StdinPromptCallbackHandler com um cliente multiencadeado no qual vários encadeamentos podem tentar obter dados de entrada padrão simultaneamente.
com.ibm.wsspi.wssecurity.auth.callback.NonPromptCallbackHandler
Essa implementação CallbackHandler não solicita dados. Em vez disso, ela utiliza os dados de autenticação básica definidos nas informações de ligação de login (estas informações não são as mesmas que as informações de autenticação básica HTTP). Essa implementação CallbackHandler é para utilização com o método de autenticação BasicAuth. Você deve definir os dados de autenticação básica nas informações sobre ligação de login dessa implementação CallbackHandler. É possível usar esse implementação quando os serviços da Web estão executando como um cliente e precisam de autenticação básica (<wsse:UsernameToken>) para chamada de recebimento de dados.
com.ibm.wsspi.wssecurity.auth.callback.LTPATokenCallbackHandler
O CallbackHandler gera tokens LTPA (Lightweight Third Party Authentication) a partir do Objeto do run as JAAS (Objeto de chamada) do contexto de segurança atual do WebSphere Application Server. Contudo, se os dados de autenticação básica forem definidos nas informações de ligação do login (não as informações de autenticação básica HTTP), a implementação utiliza os dados de autenticação básica e o token LTPA gerado. Os valores URI do Tipo de Token e Nome Local do Tipo de Token devem ser definidos nas informações sobre ligação de login para essa implementação CallbackHandler. O tipo de valor do token é utilizado para validar o token para a configuração de ligação do emissor do pedido e do receptor do pedido. O tempo de execução de segurança dos serviços da Web insere o token LTPA como um token de segurança binário (<wsse:BinarySecurityToken>) no cabeçalho SOAP da mensagem. O tipo de valor é obrigatório (Consulte LTPA para obter informações adicionais). Utilize essa implementação CallbackHandler com o método de autenticação LTPA.
A Figura 1 mostra a rotina de tratamento de segurança do emissor no processo da mensagem do emissor do pedido.
Figura 1. Processo da Mensagem SOAP do Emissor do PedidoProcesso da Mensagem SOAP do Emissor do Pedido
O servidor de segurança do receptor pode ser configurado para suportar vários métodos de autenticação e vários tipos de tokens de segurança. As etapas a seguir descrevem o processo da mensagem SOAP de emissor do pedido:
  1. Depois de receber uma mensagem, o manipulador de segurança de serviços da Web do receptor compara o tipo de token (no cabeçalho da mensagem) som os tipos de token esperados e configurados no descritor de implementação.
  2. O manipulador de segurança de serviços da Web extrai o cabeçalho da mensagem do formulário de token de segurança e mapeia o elemento <ValueType> do token com o método de autenticação correspondente. A configuração do mapeamento é definida no elemento <loginMappings> no arquivo XML ibm-webservices-bnd.xmi. Por exemplo:
    <loginMappings xmi:id="LoginMapping_1051977980074" authMethod="LTPA"
          configName="WSLogin">
         <callbackHandlerFactory xmi:id="CallbackHandlerFactory_1051977980081"
         classname="com.ibm.wsspi.wssecurity.auth.callback.WSCallbackHandlerFactoryImpl"/>
          <tokenValueType xmi:id="TokenValueType_1051977980081"
          uri="http://www.ibm.com/websphere/appserver/tokentype/5.0.2" localName="LTPA"/>
    </loginMappings>

    A interface com.ibm.wsspi.wssecurity.auth.callback.CallbackHandlerFactory é um depósito de informações do provedor para javax.security.auth.callback.CallbackHandler.

  3. O tempo de execução de segurança de serviços da Web inicia a classe de implementação de factory e transmite as informações sobre autenticação do cabeçalho de Segurança dos Serviços da Web para a classe de factory por meio dos métodos definidos.
  4. O tempo de execução de segurança dos serviços da Web chama o método newCallbackHandler() para obter o objeto javax.security.auth.CallbackHandler, que gera o token de segurança necessário.
  5. Quando o manipulador de segurança recebe um LTPA BinarySecurityToken, ele utiliza a configuração de login do JAAS WSLogin e o método newCallbackHandler() para validar o token de segurança. Se nenhum dos tipos de token esperados for localizado no cabeçalho de segurança dos serviços da Web da mensagem SOAP, o pedido é rejeitado com uma falha de SOAP. Caso contrário, o tipo do token é utilizado para mapear para uma configuração de login JAAS para validação do token. Se a autenticação obtiver êxito, um Sujeito JAAS é criado e associado ao encadeamento em execução. Caso contrário, o pedido é rejeitado com uma falha do SOAP.
    A tabela a seguir mostra os métodos de autenticação e as configurações de login JAAS.
    Tabela 1. Métodos de Autenticação e Configurações de Login JAAS. Os métodos de autenticação são mapeados para a configuração de login JAAS para validação de token.
    Método de Autenticação Configuração de Login JAAS
    BasicAuth WSLogin
    Assinatura system.wssecurity.Signature
    LTPA WSLogin
    IDAssertion system.wssecurity.IDAssertion
    A Figura 2 mostra a rotina de tratamento de segurança do receptor no processo da mensagem do receptor do pedido.
    Figura 2. Processo da Mensagem SOAP do Receptor do PedidoProcesso da Mensagem SOAP do Receptor do Pedido
    O padrão <LoginMapping> é definido nos seguintes arquivos:
    • Arquivos ws-security.xml do nível de célula e ws-security.xml do nível do servidor
    Se nada for definido nas informações do arquivo de ligação, o padrão de ws-security.xml é utilizado. Contudo, um administrador pode substituir o padrão definindo um novo elemento <LoginMapping> no arquivo de ligação.
  6. O cliente lê as informações sobre ligações padrão no arquivo ${install_dir}/properties/ws-security.xml.
  7. O componente de tempo de execução do servidor carrega os seguintes arquivos se eles existirem:
    • Arquivo ws-security.xml do nível de célula e arquivo ws-security.xml do nível do servidor. Os dois arquivos são mesclados no tempo de execução para formar um conjunto efetivo de informações de ligação padrão.

    Em um servidor de aplicativos de base o componente de tempo de execução do servidor somente carrega o arquivo ws-security.xml no nível do servidor. O arquivo ws-security.xml do lado do servidor e as informações de ligação de segurança dos serviços da Web do aplicativo são gerenciados utilizando o console administrativo. É possível especificar as informações sobre ligação durante a implementação do aplicativo usando o console administrativo. A política de segurança dos serviços da Web é definida na extensão do descritor de implementação (ibm-webservicesclient-ext.xmi) e as ligações são armazenadas na extensão de ligação do IBM® (ibm-webservicesclient-bnd.xmi). Entretanto, o arquivo ${install_dir}/properties/ws-security.xml define o valor da ligação padrão para o cliente. Se as informações sobre a ligação não forem especificadas no arquivo de ligação, o tempo de execução fará a leitura das informações de ligação a partir do arquivo ${install_dir}/properties/ws-security.xml padrão.


Ícone que indica o tipo de tópico Tópico de Conceito



Ícone de registro de data e hora Última atualização: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cwbs_loginmappings
Nome do arquivo: cwbs_loginmappings.html