Configuration du mappage d'identités entrantes

Pour le mappage d'identités entrantes, écrivez un module de connexion personnalisé et configurez WebSphere Application Server de façon à exécuter ce module le premier dans les configurations de connexion système. Lorsque vous écrivez un module de connexion personnalisé, suivez la procédure ci-après.

Procédure

  1. Si nécessaire, extrayez des rappels l'identité de l'utilisateur entrant et mappez l'identité. Cette étape a lieu dans la méthode login du module de connexion. Pour qu'une authentification soit valide, l'un des rappels NameCallback ou WSCredTokenCallback (ou les deux) doivent être présents. L'exemple de code suivant montre comment déterminer l'identité de l'utilisateur :
    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)
    	{
    		// Gère les exceptions
    		throw new WSLoginFailedException (e.getMessage(), e);
    	}
    
    	// Indique quels rappels contiennent des informations
    	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);
           // A présent, attribue la valeur du numéro utilisateur à la chaîne pour pouvoir utiliser le résultat pour le
           //  mappage ou la connexion.
    			uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueID);
    		}
    		catch (Exception e)
    		{
    			// Gère l'exception
    		}	
    	}
    	else if (uid == null)
    	{
         // Génère une exception si des données d'authentification ne sont pas valides.
         // Vous devez disposer du numéro utilisateur ou du CredToken
    		throw new WSLoginFailedException("invalid authentication data.");
    	}
    	else if (uid != null && password != null)
    	{
         // Il s'agit d'une authentification type. Vous pouvez choisir de mapper cet ID vers  
         // un autre ID ou de l'ignorer et de laisser WebSphere
    Application Server 
         // effectuer la connexion à votre place. Lorsque les mots de passe sont présentés, veillez à ne pas 
         // valider le mot de passe car il s'agit de l'authentification initiale.
    		
    		return true;
    	}
    
        // Si vous le souhaitez, mapper cet UID vers un autre élément et définissez une valeur booléenne 
        // pour identitySwitched. Si l'identité a été modifiée, effacez les attributs propagés 
        // ci-dessous afin qu'ils ne soient pas utilisés de manière inappropriée.
    	uid = myCustomMappingRoutine (uid);
    	
        // Effacez les attributs propagés car ils ne sont plus applicables à la 
        // nouvelle identité
    	if (identitySwitched)
    	{
    		((WSTokenHolderCallback) callbacks[3]).setTokenHolderList(null);
    	}
  2. Vérifiez si la propagation d'attributs s'est produite et si les attributs de l'utilisateur sont déjà présents lorsque l'identité reste identique. Vérifiez si les attributs de l'utilisateur sont déjà présents sur le serveur d'origine pour éviter les appels en double de la consultation du registre d'utilisateurs. Pour vérifier les attributs de l'utilisateur, utilisez une méthode sur le rappel WSTokenHolderCallback qui analyse les informations présentes dans le rappel pour déterminer si elles sont suffisantes pour que WebSphere Application Server crée un sujet. L'exemple de code suivant vérifie les attributs de l'utilisateur :
    boolean requiresLogin = 
    ((com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback) 
    callbacks[2]).getrequiresLogin();
    S'il n'y a pas suffisamment d'attributs présents pour former les objets WSCredential et WSPrincipal nécessaires pour procéder à l'autorisation, l'exemple de code suivant renvoie la valeur true. Lorsque le résultat est false, vous pouvez choisir d'arrêter le traitement car les informations nécessaires existent pour créer le sujet sans appeler de registres d'utilisateurs distants supplémentaires.
  3. Facultatif : Recherchez les attributs requis dans le registre d'utilisateurs, placez-les dans une table de hachage hashtable, puis ajoutez cette dernière à l'état partagé. Si l'identité est permutée dans ce module de connexion, vous devez suivre la procédure ci-après :
    1. Créez la table de hachage hashtable des attributs, comme indiqué dans l'exemple ci-dessous.
    2. Ajoutez la table de hachage hashtable à l'état partagé.
    Si l'identité n'est pas permutée mais que la valeur de l'exemple de code requiresLogin présenté précédemment est true, vous pouvez créer la table de hachage hashtable des attributs. Vous n'êtes cependant pas obligé de créer une table de hachage hashtable dans cette situation car WebSphere Application Server gère la connexion automatiquement. Toutefois, vous pouvez envisager de créer une table de hachage hashtable pour regrouper les attributs dans les cas spéciaux où vous utilisez votre propre registre d'utilisateurs particulier. La solution la plus simple consiste probablement à créer une implémentation UserRegistry, à utiliser une table de hachage hashtable et à laisser WebSphere Application Server collecter les attributs utilisateur. Le tableau suivant indique comment créer une table de hachage hashtable d'attributs d'utilisateur :
    if (requiresLogin || identitySwitched)
    	{
    		// Extrait le contexte initial par défaut pour ce serveur.
    		javax.naming.InitialContext ctx = new javax.naming.InitialContext();
    
    		// Extrait l'implémentation UserRegistry locale.
    		com.ibm.websphere.security.UserRegistry reg = (com.ibm.websphere.security.UserRegistry) 
    		ctx.lookup("UserRegistry");				
    
         // Extrait l'ID unique de registre d'utilisateur en fonction de l'UID spécifié
         // dans NameCallback.
    		String uniqueid = reg.getUniqueUserId(uid);
    	 	uid = WSSecurityPropagationHelper.getUserFromUniqueID (uniqueid);
    			
         // Extrait le nom d'affichage du registre d'utilisateurs d'après l'uniqueID.
    		String securityName = reg.getUserSecurityName(uid);
    	
         // Extrait les groupes associés à cet uniqueID.
    		java.util.List groupList = reg.getUniqueGroupIds(uid);
    			
         // Crée la java.util.Hashtable avec les informations que vous avez regroupées 
         // à partir de l'implémentation 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);
    
         // Ajoute une clé de mémoire cache qui est utilisée dans le mécanisme de recherche 
         // pour l'objet créé. La clé de mémoire cache peut être un objet, mais doit posséder 
         // une méthode toString implémentée. Assurez-vous que cacheKey contient 
         // suffisamment d'informations pour les étendre à l'utilisateur et aux autres attributs 
         // que vous utilisez. Si vous ne spécifiez pas cette propriété, le sujet est 
         // étendu sur l'élément WSCREDENTIAL_UNIQUEID renvoyé, par défaut.
    		hashtable.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_CACHE_KEY, "monAttributPersonnalisé" + uniqueid);
    		// Ajoute la table de hachage à l'état partagé du sujet.
    		_sharedState.put(com.ibm.wsspi.security.token.AttributeNameConstants.
            WSCREDENTIAL_PROPERTIES_KEY,hashtable);
    	}
    Les règles suivantes définissent plus en détail la manière d'exécuter une connexion par une table de hachage hashtable. Vous devez utiliser un objet java.util.Hashtable dans le sujet (ensemble de justificatifs publics ou privés) ou une table de hachage d'état partagé. La classe com.ibm.wsspi.security.token.AttributeNameConstants définit les clés qui contiennent les informations utilisateur. Si l'objet hashtable est placé dans l'état partagé du contexte de connexion à l'aide d'un module de connexion personnalisé figurant avant le module de connexion LTPA (Lightweight Third Party Authentication), la valeur de l'objet java.util.Hashtable est recherchée à l'aide de la clé suivante dans la table de hachage de l'état partagé suivante :
    Propriété
    com.ibm.wsspi.security.cred.propertiesObject
    Référence à la propriété
    AttributeNameConstants.WSCREDENTIAL_PROPERTIES_KEY
    Explication
    Cette clé recherche l'objet Hashtable qui contient les propriétés requises dans l'état partagé du contexte de connexion.
    Résultat prévu
    Un objet java.util.Hashtable.

    Si un objet java.util.Hashtable se trouve à l'intérieur du sujet ou dans la zone d'état partagé, vérifiez que la table de hachage contient les propriétés suivantes :

    Propriété
    com.ibm.wsspi.security.cred.uniqueId
    Référence à la propriété
    AttributeNameConstants.WSCREDENTIAL_UNIQUEID
    Retours
    java.util.String
    Explication
    La valeur de la propriété doit être une représentation unique de l'utilisateur. Pour l'implémentation par défaut de WebSphere Application Server, cette propriété représente les informations stockées dans la table d'autorisations de l'application. Ces informations se trouvent dans le descripteur de déploiement d'application après avoir été déployées et un mappage utilisateur-rôle est effectué. Si le mappage utilisateur-rôle est effectué via la recherche d'une implémentation de registre d'utilisateurs WebSphere Application Server.

    Si un fournisseur d'autorisation tiers substitue le mappage utilisateur-à-rôle, le fournisseur d'autorisations tiers définit le format. Pour assurer la compatibilité avec l'implémentation par défaut WebSphere Application Server pour la valeur d'ID unique, appelez la méthode public String getUniqueUserId(String userSecurityName) UserRegistry method de WebSphere Application Server.

    Exemples de formats requis
    Tableau 1. Exemples de format.

    Ce tableau répertorie des exemples de formats pour la configuration du mappages des identités entrantes.

    Domaine Format (uniqueUserId)
    Lightweight Directory Access Protocol (LDAP) ldaphost.austin.ibm.com:389/cn=user,o=ibm,c=us
    Windows MON_HOTE_WIN/S-1-5-21-963918322-163748893-4247568029-500
    UNIX MON_HOTE_UNIX/32

    La propriété com.ibm.wsspi.security.cred.uniqueId est requise.

    Propriété
    com.ibm.wsspi.security.cred.securityName
    Référence à la propriété
    AttributeNameConstants. WSCREDENTIAL_ SECURITYNAME
    Retours
    java.util.String
    Explication
    Cette propriété recherche le securityName de l'utilisateur de l'authentification. Ce nom est communément appelé nom d'affichage ou nom abrégé. WebSphere Application Server utilise l'attribut securityName pour les API getRemoteUser, getUserPrincipal et getCallerPrincipal. Pour assurer la compatibilité avec l'implémentation par défaut WebSphere Application Server pour la valeur securityName, appelez la méthode UserRegistry public String getUserSecurityName(String uniqueUserId) de WebSphere Application Server.
    Exemples de formats requis
    Tableau 2. Exemples de format. Ce tableau fournit des exemples de formats attendus.
    Domaine Format (uniqueUserId)
    LDAP utilisateur (numéro d'utilisateur LDAP)
    Windows user (Windows username)
    UNIX user (UNIX username)

    La propriété com.ibm.wsspi.security.cred.securityName est requise.

    Propriété
    com.ibm.wsspi.security.cred.groups
    Référence à la propriété
    AttributeNameConstants. WSCREDENTIAL_GROUPS
    Retours
    java.util.ArrayList
    Explication
    Cette clé recherche la liste de tableaux des groupes auxquels l'utilisateur appartient. Les groupes sont spécifiés au format nom_domaine/nom_utilisateur. Ce format est important car les groupes sont utilisés par le moteur d'autorisations WebSphere Application Server pour les mappages groupe-vers-rôle dans le descripteur de déploiement. Le format fourni doit correspondre à celui qui est attendu par l'implémentation par défaut de WebSphere Application Server. Lorsque vous utilisez un fournisseur d'autorisations tiers, vous devez utiliser le format attendu par ce dernier. Pour assurer la compatibilité avec l'implémentation par défaut WebSphere Application Server pour la valeur unique des ID groupe, appelez la méthode WebSphere Application Server public List getUniqueGroupIds(String uniqueUserId) UserRegistry.
    Exemples de formats requis pour chaque groupe de la liste de tableaux
    Tableau 3. Exemples de format. Ce tableau fournit des exemples de formats attendus pour chaque groupe de la liste de tableaux.
    Domaine Format
    LDAP ldap1.austin.ibm.com:389/cn=group1,o=ibm,c=us
    Windows MON_DOMAINE_WIN/S-1-5-32-544
    UNIX MONUNIX/S-1-5-32-544

    La propriété com.ibm.wsspi.security.cred.groups n'est pas requise. Les utilisateurs ne sont pas obligés d'être associés à des groupes.

    Propriété
    com.ibm.wsspi.security.cred.cacheKey
    Référence à la propriété
    AttributeNameConstants. WSCREDENTIAL_CACHE_KEY
    Retours
    java.lang.Object
    Explication
    Cette propriété de clé peut définir un objet représentant les propriétés uniques de la connexion, y compris les informations propres à l'utilisateur et les attributs dynamiques d'utilisateur pouvant avoir une incidence sur l'unicité. Par exemple, lorsque l'utilisateur se connecte depuis un emplacement A, ce qui peut avoir une incidence sur le contrôle d'accès, la clé de cache doit inclure l'emplacement A pour que le sujet reçu soit le sujet correct pour l'emplacement en cours.

    Cette propriété com.ibm.wsspi.security.cred.cacheKey n'est pas requise. Lorsqu'elle n'est pas spécifiée, la valeur de la recherche de cache est celle spécifiée pour WSCREDENTIAL_UNIQUEID. Lorsque ces informations se trouvent dans l'objet java.util.Hashtable, WebSphere Application Server crée un sujet similaire au sujet qui passe par le processus de connexion normal, au moins pour LTPA. Le nouveau sujet contient un objet WSCredential et un objet WSPrincipal entièrement renseigné avec les informations trouvées dans l'objet hashtable.

  4. Ajoutez votre module de connexion personnalisé aux configurations de connexion système JAAS (Java™ Authentication and Authorization Service) RMI_INBOUND, WEB_INBOUND et DEFAULT. Configurez la configuration de connexion RMI_INBOUND de manière que WebSphere Application Server charge d'abord votre module de connexion personnalisé.
    1. Cliquez sur Sécurité > Sécurité globale > Service JAAS (Java Authentication and Authorization Service) > Connexions au système > RMI_INBOUND.
    2. Dans Propriétés supplémentaires, cliquez sur Modules de connexion JAAS > Nouveau pour ajouter votre module de connexion à la configuration RMI_INBOUND.
    3. Revenez au panneau des modules de connexion JAAS de RMI_INBOUND.
    4. Cliquez sur Définir l'ordre pour modifier l'ordre de chargement des modules de connexion afin que WebSphere Application Server charge votre module de connexion personnalisé en premier. Utilisez le bouton Vers le haut ou Vers le bas pour organiser les modules de connexion.
    5. Répétez les trois étapes précédentes pour les configurations de connexion WEB_INBOUND et DEFAULT.

Résultats

Ce processus configure le mappage d'identités pour une demande entrante.

Icône indiquant le type de rubrique Rubrique de tâche



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_configinbidentmap
Nom du fichier : tsec_configinbidentmap.html