Avec la prise en charge SSO, les utilisateurs Web peuvent
s'authentifier une fois lorsqu'ils accèdent à des ressources Web sur plusieurs serveurs WebSphere
Application Server. Les mécanismes de connexion par formulaire des applications Web requièrent
l'activation de SSO. Cette rubrique permet de configurer une connexion unique pour la première fois.
Avant de commencer
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
SSO est pris en charge uniquement lorsque le mécanisme d'authentification est LTPA (Lightweight
Third Party Authentication).
SSO est pris en
charge lorsque le mécanisme d'authentification est LTPA (Lightweight Third Party
Authentication).
Si SSO est activé, un cookie contenant un jeton LTPA est créé et inséré dans la réponse HTTP. Lorsque l'utilisateur accède à d'autres ressources Web dans un processus WebSphere
Application Server dans le même domaine DNS, le cookie est envoyé dans la demande. Le
jeton LTPA est ensuite extrait du cookie et validé. Si la demande apparaît dans différentes cellules de serveurs d'applications WebSphere
Application Server, vous devez partager les clés LTPA et le registre d'utilisateurs entre ces cellules
pour que la fonction SSO s'exécute. Les noms de domaine sur chaque
système du domaine SSO respectent la distinction entre les majuscules et les minuscules et doivent être exactement identiques.
Pour le système d'exploitation local, le "nom de domaine" est le nom du
domaine si un domaine est utilisé. Si aucun domaine n'est utilisé, il s'agit du nom de la
machine.
![[Linux]](../images/linux.gif)
![[AIX HP-UX Solaris]](../images/unix.gif)
Le
nom de domaine est identique au nom d'hôte.
Pour le protocole LDAP (Lightweight Directory Access Protocol), le nom de domaine correspond à la valeur hôte:port du serveur LDAP. L'authentification LTPA requiert l'activation de SSO si les applications Web
utilisent une connexion par formulaire comme méthode d'authentification.
La connexion unique étant un sous-ensemble de LTPA, nous vous recommandons de lire LTPA (Lightweight Third Party Authentication) pour obtenir plus d'informations.
Lorsque vous activez la propagation d'attributs de sécurité, le cookie suivant est toujours ajouté à la réponse :
- LtpaToken2
- LtpaToken2 contient un chiffrement plus puissant et permet d'ajouter plusieurs attributs au jeton. Ce jeton contient l'identité d'authentification et d'autres informations, telles que les
attributs utilisés pour entrer en contact avec le serveur de connexion d'origine et la
clé de cache unique qui permet de rechercher le sujet lorsque l'identité n'est pas le
seul élément pris en considération pour déterminer le caractère unique des données.
Remarque : Le cookie suivant peut être ajouté à la réponse lorsque l'indicateur Mode d'interopérabilité est activé :
- LtpaToken
- LtpaToken permet de garantir l'interopérabilité avec des versions précédentes de WebSphere
Application Server. Ce jeton contient uniquement l'attribut de l'identité d'authentification.
Remarque : LtpaToken est généré pour les versions antérieures à
WebSphere
Application Server version 5.1.0.2. LtpaToken2 est généré pour
WebSphere
Application Server version 5.1.0.2 et ultérieure.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Remarque : LtpaToken est généré pour les versions antérieures à
WebSphere
Application Server version 5.1.1. LtpaToken2
est généré pour
WebSphere
Application Server version
5.1.1 et ultérieure.
Tableau 1. Types de jeton LTPA. Ce tableau décrit les types de jeton LTPA.Type de jeton |
Rôle |
Comment définir |
LtpaToken2 uniquement |
Il s'agit du type de jeton par défaut. Il utilise la force du remplissage du chiffrement AES-CBC-PKCS5 (taille de clé de 128 bits). Ce
jeton est plus fort que le jeton précédent LtpaToken utilisé avant WebSphere
Application Server version 6.02.
C'est l'option recommandée lorsque l'interopérabilité avec des versions plus anciennes n'est pas nécessaire. |
Désactivez l'option Mode d'interopérabilité dans le panneau de configuration SSO de la console d'administration.
Pour accéder à ce panneau, procédez comme suit :- Cliquez surSécurité > Sécurité globale.
- Dans le menu Sécurité Web, cliquez sur Connexion unique (SSO).
|
LtpaToken et LtpaToken2 |
Utilisez-les pour interopérer avec les versions
antérieures à WebSphere
Application Server version 5.1.1.
Le cookie LtpaToken plus ancien est présent avec le nouveau cookie LtpaToken2. Sous réserve que les clés LTPA sont correctement partagées, vous devriez pouvoir interopérer avec n'importe quelle version de WebSphere à l'aide de cette option. |
Activez l'option Mode d'interopérabilité dans le panneau de configuration SSO de la console d'administration.
Pour accéder à ce panneau, procédez comme suit :- Cliquez surSécurité > Sécurité globale.
- Dans le menu Sécurité Web, cliquez sur Connexion unique (SSO).
|
Pourquoi et quand exécuter cette tâche
La procédure ci-dessous est requise pour effectuer la première configuration de SSO.
Procédure
- Ouvrez la console d'administration.
![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
Entrez
http://localhost:numéro_port/ibm/console pour accéder à la
console d'administration dans un navigateur Web.
Entrez l'adresse
http://nom_serveur:numéro_port/ibm/console
pour accéder à la console d'administration dans un navigateur Web.
Le port 9060 est le numéro de port défini par défaut pour accéder à la console d'administration.
Lors de l'installation, il est toutefois possible que vous ayez indiqué un autre numéro de port. Utilisez le numéro de port approprié.
- Cliquez surSécurité > Sécurité globale.
- Dans le menu Sécurité Web, cliquez sur Connexion unique (SSO).
- Cliquez sur l'option Activé si SSO est désactivé. Après avoir cliqué sur l'option Activé, exécutez la procédure jusqu'à son terme.
- Cliquez sur SSL requis si toutes les demandes doivent utiliser HTTPS.
- Entrez les noms de domaine complets dans la zone Nom du domaine où SSO
est actif. Les noms de domaine indiqués doivent être complets. S'ils ne sont pas
complets, WebSphere
Application Server ne définit aucune valeur de nom de domaine pour le cookie
LtpaToken, et SSO est uniquement valide pour le serveur qui a créé le cookie.
Lorsque vous indiquez plusieurs domaines, vous pouvez utiliser les séparateurs suivants : un point-virgule
(;), un espace ( ), une virgule (,) ou le signe (|). WebSphere
Application Server recherche les noms de domaine spécifiés en procédant dans l'ordre, de gauche à droite. Chaque domaine est
comparé avec le nom d'hôte de la demande HTTP jusqu'à ce que la première correspondance soit trouvée.
Par exemple, si vous indiquez ibm.com; austin.ibm.com et
que le système détecte d'abord une correspondance dans le domaine ibm.com, WebSphere
Application Server ne continue pas la recherche dans le domaine austin.ibm.com. Cependant, si aucune correspondance n'est détectée dans le domaine ibm.com ou austin.ibm.com, WebSphere
Application Server ne définit aucun domaine pour le cookie LtpaToken.
Tableau 2. Valeurs de configuration de la zone Nom de domaine. Le tableau ci-après décrit les valeurs de configuration de la zone Nom de domaine.
Type de valeur de nom de domaine |
Exemple |
Rôle |
Vierge |
|
Le domaine n'est pas défini. Le navigateur définit donc le domaine comme étant le nom d'hôte de la requête. La connexion est uniquement valide sur cet hôte. |
Nom de domaine unique |
austin.ibm.com |
Si la requête concerne un hôte du domaine configuré, la connexion est valide pour tous les hôtes de ce domaine. Sinon, elle n'est valide que sur le nom d'hôte de la requête. |
UseDomainFromURL |
UseDomainFromURL |
Si la requête concerne un hôte du domaine configuré, la connexion est valide pour tous les hôtes de ce domaine. Sinon, elle n'est valide que sur le nom d'hôte de la requête. |
Noms de domaine multiples |
austin.ibm.com;raleigh.ibm.com |
La connexion est valide pour tous les hôtes du domaine du nom d'hôte de la requête. Avertissement : SSO interdomaine n'est pas pris en charge. Par exemple, chicago.xxx.com et cleveland.yyy.com, où
les domaines DNS sont différents.
|
Noms de domaine multiples et UseDomainFromURL |
austin.ibm.com;raleigh.ibm.com; UseDomainFromURL |
La connexion est valide pour tous les hôtes du domaine du nom d'hôte de la requête. Avertissement : SSO interdomaine n'est pas pris en charge. Par exemple, chicago.xxx.com et cleveland.yyy.com, où
les domaines DNS sont différents.
|
Si vous indiquez la valeur UseDomainFromURL,
WebSphere
Application Server définit la valeur du nom de domaine SSO sur le domaine de l'hôte qui effectue
la demande. Par exemple, si une demande HTTP provient de
server1.raleigh.ibm.com,
WebSphere
Application Server définit la valeur du nom de domaine SSO sur
raleigh.ibm.com .
Conseil : La valeur UseDomainFromURL fait la distinction majuscules/minuscules. Vous pouvez entrer
usedomainfromurl pour utiliser cette valeur.
Pour plus d'informations, voir
Paramètres de connexion unique.
- Facultatif : Activez l'option Mode d'interopérabilité si vous souhaitez que les
connexions SSO dans WebSphere
Application Server version 5.1.1 ou suivante
fonctionnent avec des versions antérieures du produit.
Cette option définit l'ancien jeton LtpaToken dans la réponse afin qu'il puisse
être envoyé à d'autres serveurs qui fonctionnent uniquement avec ce type de jeton. Sinon, seul le
jeton LtpaToken2 est ajouté.
Si vous prenez les performances en considération et que vous vous connectez uniquement à des serveurs 6.1 ou de version ultérieure sur
lesquels aucun produit dépendant du jeton LTPA (LtpaToken) n'est exécuté, n'activez pas le mode Interopérabilité. Lorsque le mode
Interopérabilité n'est pas activé, aucun jeton LTPA n'est renvoyé en réponse.
- Facultatif : Activez l'option Propagation de l'attribut de sécurité des communications entrantes Web si vous souhaitez transmettre aux serveurs frontaux les informations
ajoutées lors de la connexion à un serveur frontal spécifique. Le jeton SSO ne contient pas d'attributs confidentiels mais il peut déterminer où le serveur de connexion d'origine réside s'il a besoin de le contacter pour extraire des informations sérialisées. Il contient également la valeur de recherche en cache utilisée pour rechercher les informations sérialisées dans DynaCache, si les serveurs frontaux sont configurés dans le même domaine de réplication DRS.
Pour plus d'informations, voir Propagation des attributs de sécurité.
Important : Si vous vous trouvez dans l'une des situations indiquées ci-après, il est recommandé de désactiver l'option
Propagation de l'attribut de sécurité des communications entrantes Web pour des raisons de performances :
- Vous ne possédez pas d'informations spécifiques ajoutées au sujet lors d'une connexion et inaccessibles sur un serveur frontal différent.
- Vous n'avez pas ajouté d'attributs personnalisés au jeton PropagationToken à l'aide des API
WSSecurityHelper.
Si des informations personnalisées ne sont pas disponibles dans le sujet, réactivez
l'option
Propagation de l'attribut de sécurité des communications entrantes Web
pour déterminer si les informations sont transmises correctement à d'autres serveurs
d'applications frontaux.
Les deux propriétés personnalisées suivantes peuvent aider à améliorer les performances lorsque la propagation de l'attribut de sécurité est activée :
- com.ibm.CSI.propagateFirstCallerOnly
Sa valeur par défaut est true. Si cette propriété
personnalisée a la valeur true, le premier appelant du jeton
de propagation qui reste sur l'unité d'exécution est consigné lorsque la
propagation de l'attribut de sécurité est activée. Lorsque cette propriété a pour valeur false, tous les commutateurs appelants sont consignés, ce qui peut affecter les performances.
- com.ibm.CSI.disablePropagationCallerList
Si cette propriété
personnalisée a la valeur true la possibilité d'ajouter un appelant ou une liste d'hôtes dans le jeton
de propagation est complètement désdactivée. Cette fonction est intéressante lorsque la liste des
appelants ou des hôtes du jeton de propagation n'est pas requise dans l'environnement.
- Cliquez sur OK.
Que faire ensuite
Pour que les modifications soient appliquées, sauvegardez, arrêtez et redémarrez tous les gestionnaires de déploiement, les noeuds et les serveurs du produit.