Configuration de Security Access Manager pour l'authentification, l'autorisation et le coffre des identifications

You can configure Security Access Manager for authentication, authorization, and the vault adapter with one task.

Pourquoi et quand exécuter cette tâche

Procédure

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).
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 :
    
    Le nom configuré d'une seule instance WebSEAL, par exemple web 1
    
    La chaîne littérale -websealed-
    
    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
```
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.
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

Clustered environments : Effectuez cette étape sur tous les noeuds.

Exécutez la tâche suivante à partir du 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.

Utilisez un éditeur de texte pour ouvrir le fichier wkplc_comp.properties dans le répertoire suivant :
- AIX® HP-UX Linux™ Solaris: wp_profile_root/ConfigEngine/properties
- IBM® i: wp_profile_root/ConfigEngine/properties
- Windows™ : wp_profile_root\ConfigEngine\properties
Clustered environments : Effectuez cette étape sur tous les noeuds.
Mise à niveau des propriétés dans le wkplc_comp.properties.
1. Mettez à jour les paramètres de gestion de l'espace de nom dans le fichier wkplc_comp.properties pour la configuration des paramètres de sécurité avancée à l'aide des gestionnaires de sécurité externe.
  1. Pour wp.ac.impl.EACserverName, entrez les informations de contexte de l'espace de nom afin de faire la distinction entre les noms de rôles de portail externalisés et les autres noms de rôles dans l'espace de nom.
    Remarque : Si cette option est définie, wp.ac.impl.EACcellName et wp.ac.impl.EACappname doivent l'être aussi. Les trois paramètres doivent être définis ou aucun.
  2. Pour wp.ac.impl.EACcellName, entrez les informations de contexte de l'espace de nom pour faire la distinction entre les noms de rôles de portail externalisés et les autres noms de rôles dans l'espace de nom.
    Remarque : Si cette option est définie, wp.ac.impl.EACserverName et wp.ac.impl.EACappname doivent l'être aussi.
  3. Pour wp.ac.impl.EACappname, entrez les informations de contexte de l'espace de nom pour faire la distinction entre les noms de rôles de portail externalisés et les autres noms de rôles dans l'espace de nom.
    Remarque : Si ce paramètre est défini, wp.ac.impl.EACcellName et wp.ac.impl.EACserverName doivent l'être aussi.
  4. Pour wp.ac.impl.reorderRoles, entrez false afin de conserver l'ordre des rôles, ou true pour réorganiser les rôles par type de ressource.
2. Paramètres de la commande PDJrteCfg et du système de fichiers
  1. Pour wp.ac.impl.TamHost sous l'en-tête de paramètre de commande SvrSslCfg dans le fichier wkplc_comp.properties, entrez le serveur de règles Security Access Manager utilisé lorsque vous exécutez PDJrteCfg.
3. WebSphere® Paramètres de l'intercepteur de relations de confiance WebSEAL d'Application Server
  1. Entrez le paramètre suivants dans le fichier wkplc_comp.properties. Accédez à l'en-tête des paramètres de jonction WebSeal :
    Cluster note : Effectuez cette étape sur tous les noeuds du cluster. Les paramètres suivants doivent correspondre sur tous les noeuds de l'environnement en cluster. La seule exception est le paramètre wp.ac.impl.PDServerName.
    - 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.
  2. Entrez les paramètres suivants dans le fichier wkplc_comp.properties. Accédez à l'en-tête des paramètres d'intercepteur de relations de confiance (TAI) Webseal :
    Cluster note : Effectuez cette étape sur tous les noeuds du cluster. Les paramètres suivants doivent correspondre sur tous les noeuds de l'environnement en cluster. La seule exception est le paramètre wp.ac.impl.PDServerName.
    - Facultatif : Pour wp.ac.impl.hostnames, entrez le nom d'hôte qui définit le paramètre du nom d'hôte du TAI de WebSEAL. Cette valeur doit correspondre aux paramètres -h et -p de la commande de création de la jonction.
    - Facultatif : Pour wp.ac.impl.ports, entrez le port utilisé pour définir le paramètre des ports du TAI de WebSEAL. Cette valeur doit correspondre au paramètre -p de la commande de création de la jonction.
    - 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é.
4. Mettez à jour les paramètres suivants dans le fichier wkplc_comp.properties ; accédez à l'en-tête des paramètres d'autorisation de portail :
  1. Pour wp.ac.impl.PDRoot, entrez le nom de l'espace d'objet racine dans l'espace de nom Security Access Manager pour les entrées de ressource concernant ce portail. Tous les rôles de portail sont installés avec cette entrée. Dans le cas de plusieurs profils et instances de portail partageant une instance Security Access Manager commune, choisissez un nom unique pour chaque entrée d'espace d'objet racine. Ce nom unique vous permet de distinguer facilement les ressources des différentes instances. Ou bien, utilisez une valeur PDRoot commune pour toutes les instances de portail de sorte que tous les rôles de portail d'une instance aient un parent commun. Vous pouvez ensuite utiliser le paramètre EACappname pour distinguer les instances les unes des autres. Si cela convient mieux à vos modèles d'administration, vous pouvez également combiner ces deux approches en utilisant une valeur PDRoot commune pour certaines instances et des valeurs PDRoot uniques pour d'autres instances.
  2. Pour wp.ac.impl.PDAction, entrez l'action personnalisée créée par le plug-in d'autorisation externe Security Access Manager. La combinaison du groupe d'actions et de l'action détermine la chaîne des droits d'accès Security Access Manager. La chaîne de droits d'accès est utilisée pour affecter une appartenance à des rôles de portail externalisés. Vous souhaiterez peut-être demander à l'administrateur de Security Access Manager de préciser ce qu'il convient de faire pour les valeurs PDActionGroup et PDAction.
  3. Pour wp.ac.impl.PDActionGroup, entrez le groupe d'actions personnalisées créé par le plug-in d'autorisation externe Security Access Manager. La combinaison du groupe d'actions et de l'action détermine la chaîne des droits d'accès Security Access Manager. La chaîne des droits d'accès est utilisée pour attribuer l'appartenance à des rôles de Portal externalisés.
  4. Pour wp.ac.impl.PDCreateAcl, définissez la valeur sur true afin de créer et d'associer automatiquement une liste de contrôle d'accès Security Access Manager lorsque HCL externalise les rôles pour une ressource. Définissez la valeur sur false pour créer et associer une liste de contrôle d'accès Security Access Manager lorsque HCL externalise les rôles pour une ressource. Dans ce cas, l'administrateur Security Access Manager doit créer et associer manuellement des listes de contrôle d'accès aux entrées d'espace d'objet pour les ressources et les rôles de portail externalisés. Toute liste de contrôle d'accès créée manuellement de cette façon doit utiliser les valeurs PDAction et PDActionGroup pour que les droits soient détectés.
5. Entrez les paramètres suivants dans le fichier wkplc_comp.properties. Accédez à l'en-tête des paramètres du coffre du portail :
  Cluster note : Effectuez cette étape sur tous les noeuds du cluster. Les paramètres suivants doivent correspondre sur tous les noeuds de l'environnement en cluster. La seule exception est le paramètre wp.ac.impl.PDServerName.
  1. Pour wp.ac.impl.vaultType, entrez le nouvel identificateur de type de coffre représentant le boîtier de sécurité d'authentification unique de Tivoli®.
  2. Pour wp.ac.impl.vaultProperties, entrez le fichier utilisé pour configurer le coffre avec les informations sur l'utilisateur et la connexion SSL spécifiques à Security Access Manager.
  3. Pour wp.ac.impl.manageResources, entrez true si le coffre des identifications ou des portlets personnalisés sont autorisés à créer des objets de ressource dans Security Access Manager. Ou bien entrez false pour autoriser uniquement l'administrateur Security Access Manager à définir les ressources accessibles auxquelles associer des utilisateurs depuis la ligne de commande ou l'interface graphique.
  4. Pour wp.ac.impl.readOnly, entrez true pour autoriser le coffre des identifications ou des portlets personnalisés à modifier les valeurs confidentielles stockées dans Security Access Manager. Ou bien entrez false pour autoriser uniquement l'administrateur Security Access Manager à modifier ces valeurs confidentielles depuis la ligne de commande ou l'interface graphique.
Enregistrez vos modifications dans le fichier de propriétés.
Ouvrez une invite de commande et accédez au répertoire wp_profile_root/ConfigEngine.
Exécutez la tâche suivante pour activer l'authentification, l'autorisation et le coffre des identifications Security Access Manager :
- AIX® : ./ConfigEngine.sh enable-tam-all -DWasPassword=password
- HP-UX: ./ConfigEngine.sh enable-tam-all -DWasPassword=password
- IBM® i: ConfigEngine.sh enable-tam-all -DWasPassword=password
- Linux™ : ./ConfigEngine.sh enable-tam-all -DWasPassword=password
- Solaris: ./ConfigEngine.sh enable-tam-all -DWasPassword=password
- Windows™ : ConfigEngine.bat enable-tam-all -DWasPassword=password
Clustered environments :
- Effectuez cette étape sur tous les noeuds.
- WasPassword est le mot de passe administratif du gestionnaire de déploiement.
If the task does not run successfully : Vérifiez que les valeurs que vous avez indiquées dans le fichier wkplc_comp.properties sont valides.
Exécutez la procédure suivante pour définir la valeur de la propriété systemcred.dn :

Remarque : La propriété systemcred.dn définit le nom distinctif de l'administrateur de coffre. Toutes les données d'accréditation du système sont enregistrées sous le compte de l'utilisateur. Pour Security Access Manager, cet utilisateur doit être un utilisateur existant de Security Access Manager. L'adaptateur Security Access Manager vérifie si l'utilisateur existe dans Security Access Manager avant l'accès aux emplacements.
1. Log on to the WebSphere® Integrated Solutions Console.
2. Go to Resources > Resource Environment > Resource Environment Providers.
3. Cliquez sur WP CredentialVaultService.
4. Under Additional Properties, click Custom properties.
5. Editez la propriété systemcred.dn. Définissez la valeur sur un utilisateur Security Access Manager existant.
Facultatif : Accédez à l'option d'activation de l'approvisionnement utilisateur si vous souhaitez l'activer.
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.
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.
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.
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.
Certaines fonctions d'HCL requièrent l'utilisation des méthodesPUT 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.