Configurando o Mapeamento de Identidade de Entrada

Para mapeamento de identidade de entrada, grave um módulo de login customizado e configure o WebSphere Application Server para executar o módulo de login primeiro dentro das configurações de login do sistema. Considere as etapas a seguir ao gravar o módulo de login customizado.

Procedimento

  1. Obtenha a identidade do usuário de entrada dos retornos de chamadas e mapeie a identidade, se necessário. Essa etapa ocorre no método de login do módulo de login. Uma autenticação válida possui um ou ambos os retornos de chamada NameCallback e WSCredTokenCallback. A amostra de código a seguir mostra como determinar a identidade do usuário:
    javax.security.auth.callback.Callback callbacks[] = 
       new javax.security.auth.callback.Callback[3];
    	callbacks[0] = new javax.security.auth.callback.NameCallback("");
    	callbacks[1] = new javax.security.auth.callback.PasswordCallback
         ("Password: ", false);
    	callbacks[2] = new com.ibm.websphere.security.auth.callback.
         WSCredTokenCallbackImpl("");
    	callbacks[3] = new com.ibm.wsspi.security.auth.callback.
         WSTokenHolderCallback("");
    
    	try
    	{
    		callbackHandler.handle(callbacks);
    	} 
    	catch (Exception e)
    	{
    		// Handles exceptions
    		throw new WSLoginFailedException (e.getMessage(), e);
    	}
    
    	// Mostra quais retornos de chamadas contém informações
    	boolean identitySwitched = false;
    	String uid = ((NameCallback) callbacks[0]).getName();
    	char password[] = ((PasswordCallback) callbacks[1]).getPassword();
    	byte[] credToken = ((WSCredTokenCallbackImpl) callbacks[2]).getCredToken();
    	java.util.List authzTokenList = ((WSTokenHolderCallback) 
         callbacks[3]).getTokenHolderList();
    
    	if (credToken != null)
    	{
    		try
    		{
    			String uniqueID = WSSecurityPropagationHelper.validateLTPAToken(credToken);
    			String realm = WSSecurityPropagationHelper.getRealmFromUniqueID (uniqueID);
           // Agora defina a cadeia para o UID, para que seja possível utilizar o resultado para o
           // mapeamento ou o login.
    			uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID);
    		}
    		catch (Exception e)
    		{
    			// Manipula a exceção
    		}	
    	}
    	else if (uid == null)
    	{
         // Emite uma exceção se os dados de autenticação não forem válidos.
         // Você deve possuir o UID ou CredToken
    		throw new WSLoginFailedException("invalid authentication data.");
    	}
    	else if (uid != null && password != null)
    	{
         // Essa é uma autenticação típica. É possível escolher mapear esse ID para  
         // outro ID ou ignorá-lo e permite que WebSphere Application Server 
         // efetue login por você. Quando as senhas forem apresentadas, seja cuidadoso para não 
         // validar a senha, pois essa é a autenticação inicial.
    		
    		return true;
    	}
    
        // Se desejar, mapeie esse uid para algo diferente e defina o booleano 
        // identitySwitched. Se a identidade foi alterada, limpe os atributos propagados 
        // abaixo, para que não sejam utilizados incorretamente.
    	uid = myCustomMappingRoutine (uid);
    	
        // Limpe os atributos propagados porque eles não são mais aplicáveis 
        // à nova identidade
    	if (identitySwitched)
    	{
    		((WSTokenHolderCallback) callbacks[3]).setTokenHolderList(null);
    	}
  2. Verifique se ocorreu propagação de atributos e se os atributos do usuário já estão presentes quando a identidade permanecer a mesma. Verifique se os atributos do usuário já estão presentes a partir do servidor de envio para evitar chamadas duplicadas à consulta do registro do usuário. Para verificar os atributos do usuário, utilize um método no retorno de chamada de WSTokenHolderCallback que analisa as informações presentes no retorno de chamada para determinar se as informações são suficientes para o WebSphere Application Server criar um Assunto. A amostra de código a seguir verifica os atributos do usuário:
    boolean requiresLogin = 
    ((com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback) 
    callbacks[2]).getrequiresLogin();
    Se não houver atributos suficientes para formar os objetos WSCredential e WSPrincipal, necessários para desempenhar a autorização, a amostra de código anterior retorna um resultado true. Quando o resultado é false, é possível escolher para descontinuar o processamento, já que existem informações necessárias para criar o Subject sem desempenhar chamadas de registro do usuário remoto adicionais.
  3. Opcional: Consulte os atributos necessários a partir do registro do usuário, coloque os atributos em uma hashtable e inclua a hashtable no estado compartilhado. Se a identidade for comutada nesse módulo de login, será necessário concluir as etapas a seguir:
    1. Crie a hashtable de atributos, conforme mostrado no exemplo a seguir.
    2. Inclua a hashtable no estado compartilhado.
    Se a identidade não for comutadoda, mas o valor da amostra de código requiresLogin que foi mostrada anteriormente for true, será possível criar a hashtable de atributos. No entanto, não é necessário que você crie uma hashtable nesta situação já que o WebSphere Application Server manipula o login para você. No entanto, você pode considerar a criação de uma hashtable para reunir atributos em casos especiais nos quais você está usando seu próprio registro do usuário especial. Criar uma implementação de UserRegistry usando uma hashtable e deixar que o WebSphere Application Server reúna os atributos do usuário para você pode ser a solução mais fácil. A tabela a seguir mostra como criar uma hashtable de atributos do usuário:
    if (requiresLogin || identitySwitched)
    	{
    		// Recupera o InitialContext padrão para esse servidor.
    		javax.naming.InitialContext ctx = new javax.naming.InitialContext();
    
    		// Recupera a implementação UserRegistry local.
    		com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.
            security.UserRegistry) 
    		ctx.lookup("UserRegistry");				
    
         // Recupera o uniqueID de registro do usuário com base no uid especificado
         // no NameCallback.
    		String uniqueid = reg.getUniqueUserId(uid);
    	 	uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueid);
    			
         // Recupera o nome de exibição do registro do usuário com base no uniqueID.
    		String securityName = reg.getUserSecurityName(uid);
    	
         // Recupera os grupos associados ao uniqueID.
    		java.util.List groupList = reg.getUniqueGroupIds(uid);
    			
         // Cria java.util.Hashtable com as informações reunidas 
         // da implementação UserRegistry.
    		java.util.Hashtable hashtable = new java.util.Hashtable();
    		hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
           WSCREDENTIAL_UNIQUEID, uniqueid);
         hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
           WSCREDENTIAL_SECURITYNAME, securityName);
    		hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
           WSCREDENTIAL_GROUPS, groupList);
    
         // Inclui uma chave de cache que é utilizada como parte do mecanismo de consulta do 
         // para o Subject criado. A chave de cache pode ser um objeto, mas deve possuir 
         // um método toString implementado. Certifique-se de que cacheKey contenha 
         // informações suficientes para o escopo do usuário e quaisquer atributos adicionais 
         // que você esteja utilizando. Se você não especificar essa propriedade, o Subject 
         //  será colocado em escopo para o WSCREDENTIAL_UNIQUEID retornado, por padrão.
    		hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_CACHE_KEY, "myCustomAttribute" + uniqueid);
    		// Inclui a tabela hash no sharedState do Subject.
    		_sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_PROPERTIES_KEY,hashtable);
    	}
    As regras a seguir definem com mais detalhes como um login de hashtable é executado. Você deve utilizar um objeto java.util.Hashtable no Subject (conjunto de credenciais públicas ou privadas) ou HashMap de estado compartilhado. A classe com.ibm.wsspi.security.token.AttributeNameConstants define as chaves que contêm as informações do usuário. Se o objeto hashtable for colocado no estado compartilhado do contexto de login usando um módulo de login customizado que é listado antes do módulo de login Lightweight Third Party Authentication (LTPA), o valor do objeto java.util.Hashtable será procurado usando a chave a seguir no hashMap de estado compartilhado:
    Propriedade
    com.ibm.wsspi.security.cred.propertiesObject
    Referência à propriedade
    AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
    Explicação
    Essa chave procura pelo objeto Hashtable que contém as propriedades requeridas no estado compartilhado do contexto de login.
    Resultado Esperado
    Um objeto java.util.Hashtable.

    Se um objeto java.util.Hashtable for localizado dentro do Subject ou dentro da área de estado compartilhado, verifique se as seguintes propriedades existem na tabela hash:

    Propriedade
    com.ibm.wsspi.security.cred.uniqueId
    Referência à propriedade
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    Retorna
    java.util.String
    Explicação
    O valor da propriedade deve ser uma representação exclusiva do usuário. Para a implementação padrão do WebSphere Application Server, essa propriedade representa as informações que estão armazenadas na tabela de autorizações do aplicativo. As informações estão localizadas no descritor de implementação do aplicativo, após ele ser implementado e o mapeamento do usuário para função ser executado. Consulte os exemplos do formato esperado se o usuário para mapeamento de função for executado utilizando uma consulta para uma implementação de registro do usuário do WebSphere Application Server.

    Se um provedor de autorizações de terceiros substituir o mapeamento de usuário para função, o provedor de autorizações de terceiros definirá o formato. Para assegurar compatibilidade com a implementação padrão do WebSphere Application Server com o valor de ID exclusivo, chame o método de Cadeia pública do WebSphere Application Server getUniqueUserId(String userSecurityName) UserRegistry.

    Exemplos de Formatos Esperados
    Tabela 1. Exemplos de Formato.

    Esta tabela fornece alguns exemplos de formato durante a configuração do mapeamento de identidade de entrada.

    Região Formato (uniqueUserId)
    LDAP (Lightweight Directory Access Protocol) ldaphost.austin.ibm.com:389/cn=user,o=ibm,c=us
    Windows MYWINHOST/S-1-5-21-963918322-163748893-4247568029-500
    UNIX MYUNIXHOST/32

    A propriedade com.ibm.wsspi.security.cred.uniqueId é obrigatória.

    Propriedade
    com.ibm.wsspi.security.cred.securityName
    Referência à propriedade
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    Retorna
    java.util.String
    Explicação
    Essa propriedade procura o securityName do usuário de autenticação. Esse nome é normalmente chamado de nome de exibição ou nome abreviado. O WebSphere Application Server utiliza o atributo securityName para as interfaces de programação de aplicativos (APIs) getRemoteUser, getUserPrincipal e getCallerPrincipal. Para assegurar compatibilidade com a implementação padrão do WebSphere Application Server par ao valor securityName, chame o método de sequência pública do WebSphere Application Server getUserSecurityName(String uniqueUserId) UserRegistry.
    Exemplos de Formatos Esperados
    Tabela 2. Exemplos de Formato. Essa tabela fornece os exemplos de formatos esperados.
    Região Formato (uniqueUserId)
    LDAP usuário (UID LDAP)
    Windows user (Windows username)
    UNIX user (UNIX username)

    A propriedade com.ibm.wsspi.security.cred.securityName é obrigatória.

    Propriedade
    com.ibm.wsspi.security.cred.groups
    Referência à propriedade
    AttributeNameConstants. WSCREDENTIAL_GROUPS
    Retorna
    java.util.ArrayList
    Explicação
    Essa chave procura a lista de matrizes de grupos aos quais o usuário pertence. Os grupos são especificados no formato realm_name/user_name. O formato desses grupos é importante pois os grupos são utilizados pelo mecanismo de autorização do WebSphere Application Server para mapeamentos de grupo-para-função no descritor de implementação. O formato que é fornecido deve corresponder ao formato esperado pela implementação padrão do WebSphere Application Server. Ao utilizar um provedor de autorização de terceiros, você deve utilizar o formato esperado pelo provedor de terceiros. Para assegurar compatibilidade com a implementação padrão do WebSphere Application Server para valor de IDs de grupo exclusivo, chame o método de lista pública do WebSphere Application Server getUniqueGroupIds(String uniqueUserId) UserRegistry.
    Exemplos de formatos esperados para cada grupo na lista de matrizes
    Tabela 3. Exemplos de Formato. Essa tabela fornece exemplos de formatos esperados para cada grupo da lista de matrizes.
    Região Formato
    LDAP ldap1.austin.ibm.com:389/cn=group1,o=ibm,c=us
    Windows MYWINREALM/S-1-5-32-544
    UNIX MY/S-1-5-32-544

    A propriedade com.ibm.wsspi.security.cred.groups não é obrigatória. Não é requerido que um usuário possua grupos associados.

    Propriedade
    com.ibm.wsspi.security.cred.cacheKey
    Referência à propriedade
    AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
    Retorna
    java.lang.Object
    Explicação
    Essa propriedade da chave pode especificar um objeto que representa as propriedades exclusivas do login, incluindo as informações específicas do usuário e os atributos dinâmicos do usuário que podem afetar a exclusividade. Por exemplo, quando o usuário efetua login a partir do local A, que pode afetar seu controle de acesso, a chave de cache precisa incluir o local A para que o Subject recebido seja o Subject correto para o local atual.

    Essa propriedade com.ibm.wsspi.security.cred.cacheKey não é requerida. Quando essa propriedade não é especificada, a consulta de cache é o valor especificado para WSCREDENTIAL_UNIQUEID. Quando essas informações são localizadas no objeto java.util.Hashtable, o WebSphere Application Server cria um Assunto semelhante ao Assunto que passa pelo processo de login normal, pelo menos para LTPA. O novo Assunto contém um objeto WSCredential e um objeto WSPrincipal que é totalmente preenchido com as informações localizadas no objeto hashtable.

  4. Inclua seu módulo de login customizado nas configurações de login do sistema RMI_INBOUND, WEB_INBOUND e DEFAULT do JAAS (Java™ Authentication and Authorization Service). Configure a configuração de login RMI_INBOUND de forma que o WebSphere Application Server carregue seu novo módulo de login customizado primeiro.
    1. Clique em Segurança > Segurança Global > Java Authentication and Authorization Service >Logins do Sistema > RMI_INBOUND
    2. Em Propriedades Adicionais, clique em Módulos de Login JAAS > Novo para incluir seu módulo de login na configuração RMI_INBOUND.
    3. Retorne ao painel Módulos de Login JAAS para RMI_INBOUND.
    4. Clique em Configurar ordem para alterar a ordem na qual os módulos de login são carregados, para que o WebSphere Application Server carregue seu módulo de login customizado primeiro. Use os botões Mover para Cima ou Mover para Baixo para organizar a ordem dos módulos de login.
    5. Repita as três etapas anteriores paras as configurações de login WEB_INBOUND e DEFAULT.

Resultados

Esse processo configura o mapeamento da identidade para um pedido de entrada.

Í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_configinbidentmap
Nome do arquivo: tsec_configinbidentmap.html