Configuration de Security Access Manager pour l'authentification uniquement

HCL Digital Experience et IBM® WebSphere® Application Server prennent en charge le support des intercepteurs de relations de confiance (TAI) fournis par IBM® Security Access Manager. Si vous utilisez Security Access Manager pour l'autorisation, vous devez également utiliser Security Access Manager pour l'authentification. Using Security Access Manager only for authorization is not supported.

Pourquoi et quand exécuter cette tâche

Important information :
  • La commande pdadmin est un utilitaire qui prend en charge les fonctions d'administration de Security Access Manager.
  • Cette procédure nécessite que vous soyez familiarisé avec les concepts d'administration WebSEAL présentés dans le guide d'administration de WebSEAL. Vous trouverez les descriptions de toutes les options de la commande pdadmin permettant de créer des jonctions dans la documentation Security Access Manager, notamment le guide d'administration de WebSEAL.
  • L'exemple suivant suppose qu'un serveur Web se trouve entre WebSEAL et HCL dans le flux de demande. Par conséquent, les jonctions définies dans les instructions suivantes sont configurées pour permettre à WebSEAL d'acheminer des demandes au serveur HTTP puis à HCL. S'il n'existe pas de serveur HTTP, modifiez le nom d'hôte cible de jonction et les valeurs de port pour activer la communication directe entre WebSEAL et HCL.
  • Les exemples suivants ne montrent pas de fonction d'équilibrage de charge ou autre fonction des demandes liées aux performances dans WebSEAL. Pour plus d'informations sur ces options avancées, consultez la documentation Security Access Manager.
  • Les exemples suivants montrent des cas simples de création de jonction. Consultez le guide d'administration WebSEAL et la documentation WebSphere® Application Server appropriés pour plus d'informations sur les options avancées, y compris la génération de jetons LTPA dans WebSEAL pour SSO dans WebSphere® Application Server.
Clustered environments : Exécutez la tâche validate-pdadmin-connection sur tous les nœuds du cluster. Effectuez toutes les autres étapes sur le noeud principal.

Procédure

  1. Démarrez les serveurs de règles et d'autorisation Security Access Manager, indispensables au bon déroulement de la configuration et de la connexion unique (SSO).
  2. Créez vos jonctions sur le serveur WebSEAL. Vous trouverez des conseils sur la création de jonction dans la documentation IBM Security Access Manager for e-business. Procédez comme suit pour créer une jonction TCP d'hôte virtuel :
    1. Ouvrez une commande pdadmin à partir de tout nœud ayant un composant de phase d'exécution Security Access Manager installé. Vous pouvez utiliser le nœud Security Access Manager Server, WebSEAL ou HCL.
    2. The general format for the pdadmin command to create a virtual host junction is
      pdadmin> server task WebSEAL-instance_name-webseald-WebSEAL-HostName virtualhost create -t type -h hostname [options] vhost-label
      Les informations suivantes décrivent les paramètres obligatoires dans la commande pdadmin :
      • WebSEAL-instance_name-webseald-WebSEAL-HostName comporte trois parties, comme indiqué dans le guide d'administration WebSEAL :
        1. Le nom configuré d'une seule instance WebSEAL, par exemple web 1
        2. La chaîne littérale -websealed-
        3. Par exemple, le nom d'hôte est webseal.yourco.com

        La combinaison obtenue serait web 1-websealed-webseal.yourco.com. Vous pouvez utiliser la commande pdadmin server list pour afficher le format correct du nom de serveur.

      • Le libellé d'hôte virtuel (vhost-label) correspond au nom de la jonction d'hôte virtuel.
        • Les jonctions d'hôte virtuel sont toujours installées à la racine de l'espace d'objet WebSEAL.
        • Vous pouvez utiliser ce libellé pour faire référence à une jonction dans l'utilitaire pdadmin.
        • Le libellé de jonction d'hôte virtuel doit être unique dans chaque instance de WebSEAL.
        • Dans la mesure où le libellé représente les jonctions d'hôte virtuel dans l'espace d'objet protégé, le nom du libellé ne doit pas contenir de barre oblique (/).
      • -t type : : Ce paramètre indique si la jonction est chiffrée (-t ssl) ou non chiffrée (-t tcp). Ce paramètre est obligatoire pour la création d'une jonction d'hôte virtuel. Pour plus d'informations sur d'autres valeurs possibles, voir le guide d'administration WebSEAL.
      • -h hostname : Ce paramètre indique le serveur dorsal auquel la jonction se connecte. Dans la plupart des cas, le nom d'hôte correspond au serveur HTTP associé à HCL. Ce paramètre est obligatoire pour la création d'une jonction d'hôte virtuel.
      La variable [options] comprend les paramètres suivants :
      • -p port : Ce paramètre indique le numéro de port pour le serveur dorsal auquel la jonction se connecte. Si ce paramètre n'est pas spécifié, la valeur par défaut est 80 pour HTTP ou 443 pour HTTPS. La meilleure pratique consiste à spécifier cette valeur explicitement dans la commande de création de jonction, même si les valeurs par défaut sont utilisées.
      • -v vhost_name[:port] : Ce paramètre correspond au nom d'hôte virtuel et au numéro de port qui définit la jonction. WebSEAL mappe les requêtes entrantes pour ce nom d'hôte et ce port vers cette jonction. Si aucune valeur n'est spécifiée, la valeur par défaut est -h hostnameand-p port.
      • -c header_type : Ce paramètre insère l'identité du client Security Access Manager dans les en-têtes HTTP dans la jonction. L'argument header_type peut inclure une combinaison des en-têtes HTTP Security Access Manager suivants :
        • {iv_user|iv_user-l}
        • iv_groups
        • iv_creds
        • all
        Les types d'en-tête doivent être séparés par des virgules et il ne doit pas y avoir d'espace entre eux. Par exemple: -c iv_user,iv_groups. Indiquer -c all revient au même que spécifier -c iv_user,iv_groups,iv_creds. Ce paramètre est valable pour toutes les jonctions, sauf le type local. Ce paramètre dépend du fonctionnement que vous souhaitez pour l'intercepteur TAI au sein de WebSphere® Application Server. Pour certains modes, l'intercepteur TAI peut être à la recherche de la présence d'un ou de plusieurs de ces en-têtes. L'intercepteur TAI recherche ces en-têtes pour savoir qu'il doit réclamer la demande lorsqu'il est interrogé par la sécurité WebSphere® Application Server. Ce paramètre doit être défini pour correspondre ce que l'intercepteur TAI recherche. Adressez-vous à l'administrateur de votre système WebSphere® si vous avez des doutes sur la manière dont l'intercepteur de relations de confiance est configuré.
      • -b : cette option contrôle la façon dont WebSEAL transmet les informations d'authentification sur le serveur d'arrière-plan. Généralement, ce paramètre dépend de la façon dont vous souhaitez que l'intercepteur TAI soit configuré dans WebSphere® pour valider une relation de confiance avec WebSEAL. L'option habituelle qui est choisie est -b supply. Pour plus d'informations, voir le guide d'administration WebSEAL ou la documentation sur la configuration et l'installation d'ETAI.
      • -k : cette option contrôle si WebSEAL inclut son propre cookie de session dans la demande au serveur d'arrière-plan. Dans certains cas, l'envoi du cookie de session webSEAL au serveur d'arrière-plan est nécessaire. Cette action est nécessaire pour prendre en charge la connexion unique à partir d'HCL vers d'autres services d'arrière-plan où WebSEAL protège également ces services d'arrière-plan.
      • Remarque : Les jonctions à HCL directes ou via un serveur HTTP ne prennent pas en charge l'option -q option de la fonction query_contents. La fonction Query_contents est impossible sur HCL.
      Les informations suivantes sont un exemple de commande pour créer une jonction TCP d'hôte virtuel, sur l'instance web 1 WebSEAL qui s'exécute sur un hôte webseal.yourco.com, pour le nom d'hôte virtuel portalvhost.yourco.com s'exécutant sur le port 80 qui exige un intercepteur TAI dans WebSphere® Application Server. La jonction d'hôte virtuel est marquée vhost_junction_portal_1. Le nom d'hôte de la jonction d'hôte virtuel doit être mappé dans le DNS sur le serveur WebSEAL. The portal or http server is running on host portal.yourco.com and is using port 8080:
      pdadmin> server task web1-webseald-webseal.yourco.com virtualhost create -t tcp -v portalvhost.yourco.com:80 -h portal.yourco.com -p 8080 -c all -k -b supply vhost_junction_portal_1
  3. Facultatif : Si vous prévoyez d'utiliser une jonction SSL, plusieurs étapes sont nécessaires pour que vous puissiez créer la jonction. La clé et le fichier de clés certifiées nécessaires doivent être configurés avec les certificats appropriés pour activer SSL. Suivez les instructions fournies dans les étapes 1 à 3 de la rubrique relative à la configuration de SSL. Ensuite, procédez comme suit pour créer la jonction d'hôte virtuel :
    1. Utilisez l'utilitaire IBM® Key Management pour charger le certificat de serveur Web dans le fichier de clés pour l'instance appropriée de WebSEAL. Consultez la documentation d'HTTP Server pour plus de détails.
    2. Redémarrez WebSEAL.
    3. Suivez les étapes mentionnées plus haut pour créer la jonction. Remplacez la valeur de -t par ssl et ajoutez l'ensemble approprié d'options à partir de la portion des jonctions SSL mutuellement authentifiées du guide d'administration WebSEAL : -B, -D, -K, -U et -W.
  4. Entrez les tâches suivantes dans la ligne de commande pdadmin afin de créer le compte utilisateur sécurisé :
    Conseil : Cette étape est requise uniquement pour les jonction d'intercepteur de relations de confiance (TAI). Ignorez cette étape si vous avez créé une jonction LTPA. Une jonction LTPA est créée lorsque vous utilisez le paramètre -A. Reportez-vous à la documentation Security Access Manager for e-business pour plus d'informations sur cette configuration avancée.
    Le compte d'utilisateur sécurisé dans le registre d'utilisateurs Security Access Manager doit être identique à celui que l'intercepteur TAI dans WebSphere® Application Server est configuré pour utiliser. Il s'agit de l'ID utilisé par WebSEAL pour s'identifier auprès de WebSphere® Application Server à l'aide de l'option -b supply et constitue l'une des exigences de sécurité de l'intercepteur TAI sous-jacent.
    Remarque : Pour éviter toute défaillance, n'utilisez pas les utilisateurs sec_master ou wpsadmin pour le compte d'utilisateur approuvé. Le compte utilisateur sécurisé doit être un compte utilisateur dédié à la communication entre WebSEAL et l'intercepteur de relations de confiance.
    1. pdadmin> user create webseal_userid webseal_userid_DN firstname surname password
    2. pdadmin> user modify webseal_userid account-valid yes
  5. Clustered environments : Effectuez cette étape sur tous les noeuds.
    Exécutez la tâche suivante depuis le répertoire wp_profile_root/ConfigEngine pour valider que le fichier PdPerm.properties est correct et que la communication entre HCL et le serveur Security Access Manager fonctionne :
    Conseil : Exécutez la tâche validate-pdadmin-connection sur le nœud HCL ou sur chacun des nœuds d'un environnement de cluster. Dans un environnement de cluster, WasPassword est le mot de passe d'administrateur du gestionnaire de déploiement. wp.ac.impl.PDAdminPwd correspond au mot de passe utilisateur d'administration de Security Access Manager.
    Tableau 1. Tâche de validation par le système d'exploitation de l'existence du fichier PdPerm.properties
    Système d'exploitation Tâche
    AIX®
    ./ConfigEngine.sh validate-pdadmin-connection -DWasPassword=password 
                                                  -Dwp.ac.impl.PDAdminPwd=password
    HP-UX
    ./ConfigEngine.sh validate-pdadmin-connection -DWasPassword=password 
                                                  -Dwp.ac.impl.PDAdminPwd=password
    IBM®i
    ConfigEngine.sh validate-pdadmin-connection -DWasPassword=password 
                                                -Dwp.ac.impl.PDdAdminPwd=password
    Linux
    ./ConfigEngine.sh validate-pdadmin-connection -DWasPassword=password 
                                                  -Dwp.ac.impl.PDAdminPwd=password
    Solaris
    ./ConfigEngine.sh validate-pdadmin-connection -DWasPassword=password 
                                                  -Dwp.ac.impl.PDAdminPwd=password
    Windows
    ConfigEngine.bat validate-pdadmin-connection -DWasPassword=password 
                                                 -Dwp.ac.impl.PDAdminPwd=password
    z/OS®
    ./ConfigEngine.sh validate-pdadmin-connection -DWasPassword=password 
                                                  -Dwp.ac.impl.PDAdminPwd=password
    If the task does not run successfully : Exécutez la tâche run-svrssl-config pour créer le fichier de propriétés. Pour plus d'informations, voir Création du fichier PdPerm.properties. Exécutez ensuite la tâche validate-pdadmin-connection à nouveau. Si la tâche ne réussit pas après une seconde tentative, ne passez pas à une étape ultérieure. Le fait que la tâche n'est pas exécutée avec succès indique que votre portail ne peut pas se connecter au serveur Security Access Manager. Corrigez le problème de connectivité entre votre instance de portail et le serveur Security Access Manager.
  6. Si vous utilisez des jonctions qui nécessitent un intercepteur de relation de confiance dans WebSphere®Application Server, vous devez installer et configurer l'intercepteur TAI s'il n'a pas encore été mis en place. Pour configurer l'intercepteur de relations de confiance de Security Access Manager (TAI++), procédez comme suit :
    1. Utilisez un éditeur de texte pour ouvrir le fichier wkplc_comp.properties dans le répertoire wp_profile_root/ConfigEngine/properties. Entrez les paramètres suivants sous l'en-tête des paramètres d'intercepteur de relations de confiance WebSEAL WebSphere® Application Server :
    2. Ajoutez le nouveau paramètre TAMTAIName à la section WebSphere® Application Server WebSEAL TAI.
    3. Entrez com.ibm.ws.security.web.TAMTrustAssociationInterceptorPlus comme valeur.
    4. Pour wp.ac.impl.TAICreds, entrez les en-têtes insérés par WebSEAL et dont l'intercepteur de relations de confiance se sert pour identifier la demande comme émanant de WebSEAL. Reportez-vous aux valeurs entrées pour le paramètre -c header_type.
      Par exemple, si vous avez entré -c iv-user, la valeur pour wp.ac.impl.TAICreds est iv-user. Si vous avez entré -c all, la valeur pour wp.ac.impl.TAICreds est iv-user,iv-groups,iv-creds.
      Important : N'indiquez jamais un nom d'en-tête wp.ac.impl.TAICreds que le serveur WebSEAL n'envoie pas par le biais de la jonction.
    5. Pour wp.ac.impl.hostnames, entrez l'URL qualifiée complète pour HCL. Cette valeur doit correspondre aux paramètres -h et -p de la commande de création de la jonction.
    6. Pour wp.ac.impl.ports, entrez le numéro de port servant à accéder au serveur hôte identifié dans wp.ac.impl.hostnames. Cette valeur doit correspondre au paramètre -p de la commande de création de la jonction.
    7. Pour wp.ac.impl.loginId, entrez l'identité du proxy inverse utilisée lors de la création d'une jonction TCP. Cette valeur doit correspondre au compte utilisateur sécurisé.
    8. Pour wp.ac.impl.BaUserName, entrez l'identité du proxy inverse utilisée lors de la création d'une jonction SSL.
    9. Pour wp.ac.impl.BaPassword, entrez le mot de passe pour l'ID du proxy inverse de la jonction SSL.

      Enregistrez vos modifications dans le fichier de propriétés.

    10. Exécutez la tâche suivante pour configurer le TAI pour Security Access Manager :
      Clustered environments : WasPassword est le mot de passe administratif du gestionnaire de déploiement. wp.ac.impl.PDAdminPWD correspond au mot de passe utilisateur d'administration de Security Access Manager.
      Tableau 2. Tâche de configuration de l'intercepteur de relations de confiance Security Access Manager par système d'exploitation
      Système d'exploitation Tâche
      AIX®
      ./ConfigEngine.sh enable-tam-tai -DWasPassword=password 
                                       -Dwp.ac.impl.PDAdminPwd=password
      HP-UX
      ./ConfigEngine.sh enable-tam-tai -DWasPassword=password 
                                       -Dwp.ac.impl.PDAdminPwd=password
      IBM®i
      ConfigEngine.sh enable-tam-tai -DWasPassword=password 
                                     -Dwp.ac.impl.PDAdminPwd=password
      Linux
      ./ConfigEngine.sh enable-tam-tai -DWasPassword=password 
                                       -Dwp.ac.impl.PDAdminPwd=password
      Solaris
      ./ConfigEngine.sh enable-tam-tai -DWasPassword=password 
                                       -Dwp.ac.impl.PDAdminPwd=password
      Windows
      ConfigEngine.bat enable-tam-tai -DWasPassword=password 
                                      -Dwp.ac.impl.PDAdminPwd=password
      z/OS®
      ./ConfigEngine.sh enable-tam-tai -DWasPassword=password 
                                       -Dwp.ac.impl.PDAdminPwd=password
  7. Facultatif : Activez l'application des accès utilisateur.
    Vous devez effectuer cette tâche uniquement si vous utilisez HCL pour créer des utilisateurs et leur accorder des accès directement dans LDAP, et si vous souhaitez que ces utilisateurs soient également reconnus par Security Access Manager. Dans un déploiement en entreprise d'HCL, cette tâche serait inhabituelle, car la plupart des déploiements à grande échelle appliquent un processus d'application des accès utilisateur distinct, éventuellement à l'aide d'IBM® Security Identity Manager. HCL lit à partir de LDAP, mais ne crée pas d'utilisateurs. Pour plus d'informations, voir la section des liens connexes.
  8. Si vous utilisez Security Access Manager intégré à HCL dans un environnement autonome qui ne comprend pas de serveur Web entre WebSEAL et Portal, procédez comme suit :
    1. Log on to the WebSphere® Integrated Solutions Console.
    2. Accédez à Serveurs > Types de serveurs > Serveurs d'applications Web > WebSphere_Portal > Paramètres du conteneur Web > Conteneur Web, puis cliquez sur Propriétés supplémentaires > Propriétés personnalisées.
    3. Cliquez sur Nouvelle et ajoutez la propriété personnalisée com.ibm.ws.webcontainer.extracthostheaderport avec la valeur true.
    4. Cliquez sur OK.
    5. Cliquez sur Nouvelle et ajoutez la propriété personnalisée trusthostheaderport avec la valeur true.
    6. Cliquez sur OK.
    7. Cliquez sur Enregistrer pour enregistrer vos modifications.
    8. Log out of the WebSphere® Integrated Solutions Console.
  9. Arrêtez et redémarrez les serveurs appropriés afin d'appliquer les modifications. Pour obtenir des instructions spécifiques, accédez à Démarrage et arrêt des serveurs, des gestionnaires de déploiement et des agents de nœud.
  10. Accédez au nœud WebSEAL et éditez le fichier webseald-instance.conf pour l'instance WebSEAL appropriée. Par exemple : webseald-default.conf. Ce fichier définit la valeur de basicauth-dummy-passwd sur le mot de passe pour l'ID que WebSEAL utilise pour s'identifier auprès de WebSphere® Application Server. Ce mot de passe correspond à l'ID utilisateur et au mot de passe qui ont été créés lors d'une étape précédente. Arrêtez et démarrez le serveur WebSEAL avant de continuer.
  11. Si votre instance WebSEAL est située sur le système d'exploitation Windows, limitez la longueur des URL générées. Editez le fichier webseald-instance.conf et remplacez la valeur de la propriété process-root-requests par filter pour éviter les problèmes avec le traitement WebSEAL.
  12. Importez les utilisateurs et les groupes HCL dans Security Access Manager. Entrez les commandes suivantes dans la commande d'administration de Security Access Managerwpsadmin est l'ID utilisateur de l'administrateur et wpsadmins le nom de groupe des administrateurs. Les noms distinctifs complets des ID utilisateur et de groupe varient en fonction de vos paramètres LDAP.
     user import wpsadmin uid=wpsadmin,cn=users,dc=ibm,dc=com
     user modify wpsadmin account-valid yes
     group import wpsadmins cn=wpsadmins,cn=groups,dc=ibm,dc=com
    
  13. Certaines fonctions d'HCL requièrent l'utilisation des méthodes PUT et DELETE HTTP. Par défaut, WebSEAL n'autorise pas ces requêtes. Vous devez soit autoriser ces méthodes au niveau de la liste de contrôle d'accès WebSEAL et du serveur Web applicables, soit modifier les méthodes HTTP dans la configuration x-method-override dans le fichier de configuration WebSEAL webseald-instance.conf.