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
- 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); }
- 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 :
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.boolean requiresLogin = ((com.ibm.wsspi.security.auth.callback.WSTokenHolderCallback) callbacks[2]).getrequiresLogin();
- 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 :
- Créez la table de hachage hashtable des attributs, comme indiqué dans l'exemple ci-dessous.
- Ajoutez la table de hachage hashtable à l'état partagé.
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.
- 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é.
- Cliquez sur Sécurité > Sécurité globale > Service JAAS (Java Authentication and Authorization Service) > Connexions au système > RMI_INBOUND.
- Dans Propriétés supplémentaires, cliquez sur Modules de connexion JAAS > Nouveau pour ajouter votre module de connexion à la configuration RMI_INBOUND.
- Revenez au panneau des modules de connexion JAAS de RMI_INBOUND.
- 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.
- Répétez les trois étapes précédentes pour les configurations de connexion WEB_INBOUND et DEFAULT.
Résultats
Sous-rubriques
Exemple : Module de connexion personnalisé pour le mappage entrant
Cet exemple présente un module de connexion personnalisé qui crée une table de hachage java.util.Hashtable d'après le rappel NameCallback indiqué. La table de hachage java.util.Hashtable est ajoutée à la mappe sharedState java.util.Map de sorte que les modules de connexion WebSphere Application Server puissent localiser les informations dans la table de hachage.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tsec_configinbidentmap
Nom du fichier : tsec_configinbidentmap.html