Desenvolvendo Logins Programáticos com o Java Authentication and Authorization Service

Utilize este tópico para desenvolver logins programáticos com o Java™ Authentication and Authorization Service.

Antes de Iniciar

O JAAS (Java Authentication and Authorization Service) representa a API (Interface de Programação de Aplicativos) estratégica para autenticação.

[AIX Solaris HP-UX Linux Windows][IBM i]O JAAS substitui as APIs (Interface de Programação de Aplicativo) do login programático CORBA (Common Object Request Broker Architecture).

O WebSphere Application Server fornece algumas extensões para o JAAS:
  • Consulte as informações sobre o desenvolvimento de aplicativos que utilizam CosNaming (CORBA Naming interface) para obter detalhes sobre como configurar o ambiente para aplicativos thin client para acessar recursos remotos em um servidor.
  • Se o aplicativo utilizar uma configuração de login customizada do JAAS, verifique se a configuração de login do JAAS está definida corretamente. Veja detalhes em Configurando os logins programáticos para o JAAS (Java Authentication and Authorization Service).
  • Algumas das APIs do JAAS são protegidas por permissões de segurança Java 2. Se essas APIs forem utilizadas pelo código do aplicativo, verifique se essas permissões foram adicionadas ao arquivo was.policy do aplicativo.
    Para obter detalhes, consulte os seguintes artigos: Para obter detalhes adicionais sobre quais APIs são protegidas por permissões de segurança Java 2, consulte a documentação de APIs públicas do IBM® Developer Kit, Java Technology Edition; JAAS e do WebSphere Application Server no artigo Segurança: Recursos para Aprendizado.
    Algumas das APIs utilizadas no código de amostra desta documentação e as permissões de segurança Java 2 que são necessárias a essas APIs estão na lista a seguir:
    • Os construtores javax.security.auth.login.LoginContext são protegidos pelo objeto "createLoginContext" de javax.security.auth.AuthPermission.
    • Os métodos javax.security.auth.Subject.doAs e com.ibm.websphere.security.auth.WSSubject.doAs são protegidos pelo objeto "doAs" do javax.security.auth.AuthPermission.
    • Os métodos javax.security.auth.Subject.doAsPrivileged e com.ibm.websphere.security.auth.WSSubject.doAsPrivileged são protegidos pelo objeto "doAsPrivileged" do javax.security.auth.AuthPermission.
  • Modelo aprimorado para os recursos do Java EE (Java Platform, Enterprise Edition) para verificações de autorização.

    Devido a um equívoco de design no JAAS Versão 1.0, o método javax.security.auth.Subject.getSubject não retorna o Subject associado ao encadeamento em execução dentro de um bloco de código java.security.AccessController.doPrivileged. Este equívoco pode apresentar um comportamento inconsistente, que pode ter efeitos não desejados. A classe com.ibm.websphere.security.auth.WSSubject fornece uma solução alternativa para associar um Assunto a um encadeamento em execução. A classe com.ibm.websphere.security.auth.WSSubject estende o modelo JAAS para os recursos do Java EE (Java Platform, Enterprise Edition) para verificações de autorização. Se o Assunto for associado ao encadeamento em execução no método com.ibm.websphere.security.auth.WSSubject.doAs ou se o bloco de código com.ibm.websphere.security.auth.WSSubject.doAsPrivileged contiver credenciais do produto, o Assunto será utilizado para verificações de autorização de recursos do Java EE.

  • Suporte à Interface com o Usuário para Definir Nova Configuração de Login do JAAS.
    Você pode configurar uma configuração de login do JAAS no console administrativo e armazenar a configuração de login do JAAS em um repositório de configuração. Os aplicativos podem definir uma nova configuração de login do JAAS no console administrativo e os dados persistirem no repositório de configuração. Entretanto, o WebSphere Application Server ainda suporta o formato padrão de configuração de login do JAAS (arquivo de texto simples) que é fornecido pela implementação padrão de JAAS. Se as configurações de login duplicadas estiverem definidas no repositório de configuração e no formato de arquivo de texto comum, aquele no repositório terá precedência. As vantagens de definir a configuração de login no repositório de configuração incluem:
    • O suporte ao console administrativo na definição da configuração de login do JAAS
    • Gerenciamento central da configuração de login JAAS
    • Distribuição da Configuração de Login do JAAS
  • Suporte do aplicativo à autenticação programática.

    O WebSphere Application Server fornece configurações de login do JAAS para os aplicativos desempenharem a autenticação programática no tempo de execução de segurança do WebSphere. Estas configurações executam autenticação no mecanismo de autenticação configurado pelo WebSphere Application Server (Simple WebSphere Authentication Mechanism (SWAM), Lightweight Third Party Authentication (LTPA)) e pelo registro do usuário (S.O. Local, Lightweight Directory Access Protocol (LDAP), registros customizados ou repositórios federados) e autenticação Kerberos baseada nos dados de autenticação fornecidos. O Assunto autenticado a partir dessas configurações de login do JAAS contém o proprietário e as credenciais necessárias que o tempo de execução de segurança do WebSphere pode utilizar para desempenhar verificações de autorização em recursos protegidos baseados em função do Java EE.

    Nota: SWAM está reprovado no WebSphere Application Server Versão 9.0 e será removido em um release futuro.
    Estas são as configurações de login do JAAS fornecidas pelo WebSphere Application Server:
    • Configuração de login do JAAS WSLogin. Uma configuração de login do JAAS genérica pode utilizar clientes Java, aplicativos de contêiner do cliente, servlets, arquivos JSP (JavaServer Pages) e componentes EJB (Enterprise JavaBeans) para desempenhar a autenticação baseada em um ID do usuário e senha ou um token no tempo de execução de segurança para o WebSphere Application Server. No entanto, essa configuração não considera a rotina de tratamento CallbackHandler especificada no descritor de implementação do contêiner do cliente.
    • Configuração de login WSKRB5Login JAAS. Uma configuração genérica de login JAAS pode usar clientes Java, aplicativos do contêiner do cliente, servlets, arquivos JavaServer Pages (JSP) e componentes Enterprise JavaBeans™ (EJB) para executar autenticação com base em um ID do usuário e uma senha, ou um token para o tempo de execução de segurança para o WebSphere Application Server. No entanto, essa configuração não considera o manipulador CallbackHandler especificado no descritor de implementação do contêiner do cliente.
    • Configuração de login do JAAS ClientContainer. Essa configuração de login do JAAS considera o manipulador CallbackHandler especificado no descritor de implementação do contêiner do cliente. O módulo de login desta configuração de login utiliza o manipulador CallbackHandler no descritor de implementação do contêiner do cliente, se especificado, mesmo que o código do aplicativo tenha especificado um manipulador de retorno de chamada no contexto de login. Isso é para um aplicativo de contêiner do cliente.

      Um Assunto autenticado com as configurações de login do JAAS mencionadas anteriormente contém um proprietário com.ibm.websphere.security.auth.WSPrincipal e uma credencial com.ibm.websphere.security.cred.WSCredential. Se o Assunto autenticado for transmitido no com.ibm.websphere.security.auth.WSSubject.doAs ou nos outros métodos doAs, o tempo de execução de segurança do produto poderá desempenhar verificações de autorização nos recursos Java EE baseados no Assunto com.ibm.websphere.security.cred.WSCredential.

  • Configurações de login do JAAS definidas pelo cliente.

    É possível definir outras configurações de login JAAS para executar o login programático que cria um Assunto customizado no processo do cliente ou do servidor. Determinadas credenciais e proprietários são necessários no Assunto para que o tempo de execução de segurança do produto utilize-o para enviar informações sobre autenticação do cliente sobre um protocolo ou para utilizá-lo para tratar da autorização no servidor. As credenciais necessárias são geradas a partir dos módulos de login fornecidos.

    O módulo de login necessário para um login de cliente Java puro é o seguinte:
    • com.ibm.ws.security.common.auth.module.WSLoginModuleImpl required;
    Além de utilizar esse módulo de login, o manipulador de retorno de chamada utilizado deve conseguir manipular as seguintes classes de retorno de chamada.
    • javax.security.auth.callback.NameCallback
    • javax.security.auth.callback.PasswordCallback
    Um nome do usuário e a senha devem ser especificados no manipulador de retorno de chamada. As classes customizadas que são incluídas no Assunto no lado do cliente devem ser propagadas no servidor automaticamente sempre que a propagação do atributo de segurança for ativada. É possível configurar a senha como nula, se desejar usar a asserção de identidade sem uma senha.
    Para obter informações sobre como ativar a propagação para um cliente Java puro, consulte a etapa correspondente em Propagando os Atributos de Segurança entre os Servidores de Aplicativos.
    Nota: As classes incluídas no Assunto devem ser serializáveis e desserializáveis em Java para que isso ocorra apropriadamente.
    Os módulos de login necessários para um login do servidor são os seguintes:
    • com.ibm.ws.security.server.lm.ltpaLoginModule required;
    • com.ibm.ws.security.server.lm.wsMapDefaultInboundLoginModule required;
    Para obter informações sobre os retornos de chamada utilizados para uma configuração de login do lado do servidor, consulte Customizando uma autenticação do Java Authentication and Authorization Service e a configuração de login do lado do servidor.
  • Requisitos de nomenclatura para login programático em um cliente Java puro.

    Quando o login programático ocorre em um cliente Java puro e a propriedade com.ibm.CORBA.validateBasicAuth é igual a true, é necessário que o código de segurança saiba onde o SecurityServer reside. Geralmente, o InitialContext padrão é suficiente quando uma propriedade java.naming.provider.url é configurada como uma propriedade do sistema ou quando a propriedade é configurada no arquivo jndi.properties. Em outros casos, não é desejável ter as mesmas propriedades java.naming.provider.url configuradas em um escopo do sistema inteiro. Nesse caso, há a necessidade de especificar informações de auto-inicialização específicas da segurança no arquivo sas.client.props. As etapas a seguir apresentam a ordem de precedência para determinar como localizar o SecurityServer em um cliente Java puro:

Nota: Configure com.ibm.CORBA.validateBasicAuth=false sempre que conectar-se a um servidor z/OS. Essa função não funciona atualmente de um cliente distribuído para um servidor z/OS porque o SecurityServer é localizado utilizando o proprietário UNAUTHENTICATED, que não é aceito em um sistema z/OS.

Procedimento

  1. Utilize o arquivo sas.client.props e procure as seguintes propriedades:
    com.ibm.CORBA.securityServerHost=myhost.mydomain
    com.ibm.CORBA.securityServerPort=mybootstrap port
    Se você especificar essas propriedades, terá certeza de que a segurança procurará aqui o SecurityServer. O host e a porta especificados podem representar qualquer host e porta de auto-inicialização do WebSphere. O SecurityServer reside em todos os processos de servidor e, portanto, não é importante qual host ou porta é escolhido. Se especificado, a infra-estrutura da segurança no processo do cliente procura o SecurityServer com base nas informações do arquivo sas.client.props.
  2. Coloque o código a seguir no aplicativo cliente para obter um novo InitialContext():
    ...
       import java.util.Hashtable;
      	import javax.naming.Context;
      	import javax.naming.InitialContext;
      	...
       
    // Execute um InitialContext e consulte o padrão antes de efetuar login 
    // para que a região de destino e o host/porta de auto-inicialização possam 
    // ser determinados para consulta SecurityServer.
       
       			Hashtable env = new Hashtable();
       			env.put(Context.INITIAL_CONTEXT_FACTORY, 			"
                  com.ibm.websphere.naming.WsnInitialContextFactory");
       			env.put(Context.PROVIDER_URL, 			
                  "corbaloc:iiop:myhost.mycompany.com:2809");
       			Context initialContext = new InitialContext(env);
       			Object obj = initialContext.lookup("");
    
    			// o código de login programático aparece aqui.
    Execute esta etapa antes de executar qualquer login programático. É neste código que você especifica um provedor de URL para seu contexto de nomenclatura, mas deve apontar para um WebSphere Application Server válido na célula para a qual a autenticando está sendo feita. Apontar para uma célula permite que logins programáticos específicos do encadeamento alcancem células diferentes para que tenham uma única localização do SecurityServer no sistema inteiro.
  3. Utilize o novo método InitialContext() padrão que conta com as regras de precedência de nomenclatura descritas no exemplo sobre como obter o contexto inicial padrão

Exemplo: Logins Programáticos Usando BasicAuth

Esse exemplo ilustra como os programas de aplicativos podem executar um login programático usando BasicAuth.

Inclua logins programáticos com o token do Kerberos:

LoginContext lc = null;
            
 try {
       lc = new LoginContext("WSKRB5Login",         
                  new WSCallbackHandlerImpl("userName", "password"));
 } catch (LoginException le) {
        System.out.println("Cannot create LoginContext. " + le.getMessage());
        // Insert the error processing code 
 } catch(SecurityException se) {
        System.out.println("Cannot create LoginContext." + se.getMessage());
        // Insert the error processing code
  }

  try {
         lc.login(); 
  } catch(LoginException le) {
         System.out.println("Fails to create Subject. " + le.getMessage());
          // Insert the error processing code

Como mostra o exemplo, o novo contexto de login é inicializado com a configuração de login WSKRB5Login e com o manipulador de retorno de chamada WSCallbackHandlerImpl. Use a instância WSCallbackHandlerImpl em um aplicativo no lado do servidor onde não deseja receber solicitação. Uma instância do WSCallbackHandlerImpl é inicializada pela informações de ID do usuário, senha e domínio especificadas. A implementação da classe Krb5LoginModuleWrapperClient atual que é especificada pela configuração de login WSKRB5Login pode recuperar apenas as informações de autenticação a partir do manipulador de retorno de chamada especificado. É possível construir um contexto de login com o objeto Assunto, porém o objeto Assunto é desconsiderado pela implementação Krb5LoginModuleWrapperClient atual.

Para um cliente de aplicativo Java puro, o produto fornece duas outras implementações do manipulador de retorno de chamada: WSStdinCallbackHandlerImpl e WSGUICallbackHandlerImpl, que solicitam o ID do usuário, senha e domínio na linha de comandos e no painel pop-up, respectivamente. É possível escolher uma dessas implementações do manipulador do retorno de chamada do produto, dependendo do ambiente do aplicativo específico. É possível desenvolver um novo manipulador de retorno de chamada se nenhuma dessas implementações se adequarem ao seu requisito de aplicativo específico.

Há retornos de chamada adicionais que podem ser usados com WSKRB5Login, WSAuthMechOidCallbackImpl e WSCcacheCallBackHandlerImpl. O WSAuthMechOidCallbackImpl permite especificar o OID do mecanismo de autenticação, em que o valor do OID do mecanismo de autenticação do Kerberos é "1.2.840.113554.1.2.2". O WSCcacheCallBackHandlerImpl permite especificar o nome de usuário, o nome da região do Kerberos, o caminho completo do cache de credenciais do Kerberos e se deseja usar o local padrão do cache de credenciais do Kerberos. Se escolher usar o local padrão do cache de credenciais do Kerberos, o cache de credenciais do Kerberos será ignorado. Se estiver usando o Kerberos para autenticação, será necessário atualizar o arquivo sas.client.props.

Também é possível desenvolver seu próprio módulo de login se a implementação WSLoginModuleImpl padrão falhar ao atender todos os seus requisitos. Esse produto fornece funções de utilitário que o módulo de login customizado pode utilizar, que estão descritas na próxima seção.

[AIX Solaris HP-UX Linux Windows][z/OS]Nos casos em que nenhuma propriedade java.naming.provider.url estiver configurada como uma propriedade do sistema ou no arquivo jndi.properties, um contexto InitialContext padrão não funcionará se o servidor do produto não estiver no local localhost:2809. Neste caso, construa um novo contexto InitialContext programaticamente, anterior ao login do JAAS. O JAAS precisa saber onde o servidor de segurança reside, para verificar se o ID do usuário ou senha inseridos estão corretos antes de executar um método de confirmação. Com a construção de um novo contexto InitialContext da maneira especificada posteriormente neste tópico, o código de segurança tem as informações necessárias para encontrar o local do servidor de segurança e a região de destino.

[IBM i]Nos casos em que nenhuma propriedade java.naming.provider.url estiver configurada como uma propriedade do sistema ou no arquivo jndi.properties, um contexto InitialContext padrão não funcionará se o servidor do produto não estiver no local server_name:2809. Neste caso, construa um novo contexto InitialContext programaticamente, anterior ao login do JAAS. O JAAS precisa saber onde o servidor de segurança reside, para verificar se o ID do usuário ou senha inseridos estão corretos antes de executar um método de confirmação. Com a construção de um novo contexto InitialContext da maneira especificada posteriormente neste tópico, o código de segurança tem as informações necessárias para encontrar o local do servidor de segurança e a região de destino.

Atenção: A primeira linha que inicia com env.put foi dividida em duas linhas apenas para fins de ilustração.
import java.util.Hashtable;
   import javax.naming.Context;
   import javax.naming.InitialContext;
   ...
   
// Perform an InitialContext and default lookup prior to logging in so that target realm
// and bootstrap host/port can be determined for SecurityServer lookup.
   
   Hashtable env = new Hashtable();
   env.put(Context.INITIAL_CONTEXT_FACTORY, 
           "com.ibm.websphere.naming.WsnInitialContextFactory");
   env.put(Context.PROVIDER_URL, "corbaloc:iiop:myhost.mycompany.com:2809");
   Context initialContext = new InitialContext(env);
   Object obj = initialContext.lookup("");
   
    LoginContext lc = null;
    try {
       lc = new LoginContext("WSLogin",         
                  new WSCallbackHandlerImpl("userName", "realm", "password"));
    } catch (LoginException le) {
        System.out.println("Cannot create LoginContext. " + le.getMessage());
        // inserir códido de processamento de erro 
    } catch(SecurityException se) {
        System.out.printlin("Cannot create LoginContext." + se.getMessage();
        // Inserir processamento de erro 
    }

    try {
         lc.login(); 
    } catch(LoginException le) {
         System.out.printlin("Fails to create Subject. " + le.getMessage());
          // Insert error processing code
    }

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



Í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=tsec_pacs
Nome do arquivo: tsec_pacs.html