Configuration de la connexion unique pour les portlets avec SAM et SPNEGO

Configurez les portails HCL Connections pour qu'ils utilisent la connexion unique (SSO) avec IBM Security Access Manager et SPNEGO.

Pourquoi et quand exécuter cette tâche

Single sign-on (SSO) enables users to log in to an HCL Connections application and switch to other applications within the product without having to authenticate again.

Il existe plusieurs façons de configurer la connexion unique. Cette procédure décrit une approche utilisant le protocole d'authentification Kerberos. Cette méthode d'authentification permet à Security Access Manager et aux navigateurs web des utilisateurs de se prouver mutuellement leurs identités en toute sécurité. Une fois que les utilisateurs se sont connectés à leurs systèmes client Active Directory Windows™, ils sont automatiquement connectés à Security Access Manager et HCL Connections.

En configurant HCL Connections et HCL Portal pour qu'ils partagent un même gestionnaire de déploiement, vous gagnez du temps d'administration en regroupant les tâches d'administration pour les deux applications. L'établissement d'un environnement de connexion unique est profitable pour les utilisateurs en créant un environnement plus transparent entre les deux applications.

Procédure

Avant de fédérer Portal en tant que nœud géré du gestionnaire de déploiement d'HCL Connections, vérifiez que les domaines (realms) sont identiques entre le gestionnaire de déploiement HCL Connections et Portal.
Si vous devez changer leur nom afin qu'ils concordent, consultez la rubrique Changement du nom de domaine (realm).
Procédez comme suit pour collecter les fichiers sur le noeud principal et les copier sur le gestionnaire de déploiement :
1. A partir du répertoire wp_profile_root/ConfigEngine du nœud principal, exécutez cette tâche : ConfigEngine.bat collect-files-for-dmgr -DWasPassword=password .
  Cette tâche crée un fichier compressé contenant tous les fichiers qui doivent être copiés sur le gestionnaire de déploiement. Le fichier compressé, nommé filesForDmgr.zip, est placé dans le répertoire wp_profile_root/filesForDmgr.
2. Arrêtez le gestionnaire de déploiement.
3. Développez chacun des fichiers du fichier filesForDmgr.zip dans l'emplacement approprié sur le gestionnaire de déploiement en fonction des noms de répertoire dans le fichier compressé. Les noms de répertoire dans le fichier compressé sont fondés sur les noms de répertoire par défaut habituels. Le répertoire appelé AppServer/profiles/Dmgr01 est utilisé pour identifier la racine du profil du gestionnaire de déploiement, et le répertoire AppServer pour identifier le répertoire principal d'installation du gestionnaire de déploiement. Si le gestionnaire de déploiement a été installé dans le répertoire par défaut (AppServer) et si le profil a été créé dans le répertoire par défaut (AppServer/profiles/Dmgr01), le fichier compressé peut être développé directement dans le répertoire au-dessus du répertoire AppServer.
  Par exemple : /IBM/WebSphere
4. Démarrez le gestionnaire de déploiement.
Pour étendre (augmenter) un profil de gestionnaire de déploiement, exécutez la commande suivante à partir du répertoire AppServer_root/bin :
```
manageprofiles.bat -augment -templatePath  c:/IBM/WebSphere/AppServer/profileTemplates/management.portal.augment -profileName Dmgr01
```
Redémarrez le gestionnaire de déploiement.
Ajoutez le même groupe d'administration Portal que celui d'un administrateur sur le gestionnaire de déploiement d'HCL Connections.

Exécutez la commande suivante à partir du répertoire wp_profile_root/bin afin de fédérer le noeud principal :

addNode.bat dmgr_hostname dmgr_port -includeapps -includebuses
-username was_admin_user
-password was_admin_password

Par exemple:

addNode.bat DMhost.cn.ibm.com 8879 -includeapps -includebuses -username adminuser -password adminpwd

Sur le serveur Portal, exécutez syncNode.bat, puis redémarrez le gestionnaire de déploiement et tous les agents de nœud.
Pour configurer le serveur web IBM® HTTP Server avec la connexion unique, supprimez-le puis rajoutez-le dans la console WebSphere® Application Server Integrated Solutions Console. Cela aura pour effet de remapper toutes les applications, y compris Portal, et d'importer le certificat du serveur Portal dans IBM® HTTP Server.
Ignorez cette étape si vous déployez sur Portal 8. Pour configurer la même connexion unique SPNEGO pour Portal et Connections :
1. Créez un utilisateur pour le serveur hôte Portal sur AD.
2. Créez un fichier de clés pour le serveur Portal sur AD：
```
ktpass -out path_to_keytab –princ SPN

-mapuser account_name -mapOp set –pass account_password
```
  Où :
  - path_to_keytab est le chemin dans lequel vous voulez stocker le fichier de clés généré.
  - SPN est le nom de principal du service Kerberos.
  - account_name est le nom du compte du service.
  - account_password est le mot de passe associé au compte du service.
  Par exemple:
```
ktpass -princ HTTP/portal.cn.ibm.com@cn.ibm.com -out c:\portal.keytab -mapuser portaluser -mapOp set -pass Passw0rd
```
3. Fusionnez le fichier de clés de Portal dans le fichier de clés de Connections fusionné en exécutant la commande ktab avec l'option suivante :
```
-m source_keytab_name destination_keytab_name
```
  Où :
  - source_keytab_name est le nom du fichier de clés sur le système source.
  - destination_keytab_name est le nom du fichier de clés sur le système cible.
  Par exemple:
```
c:\IBM\WebSphere\AppServer\java\jre\bin>ktab.exe -m y:\SPNEGO\portal.keytab y:\SPNEGO\merged.keytab
```
4. Recréez le fichier krb5.conf avec le nouveau fichier de clés fusionné :
```
$AdminTask createKrbConfigFile

{

-krbPath appserver\java\jre\lib\security\krb5.conf

-realm REALM

-kdcHost kdc_hostname

-dns dns_hostname

-keytabPath path_to_keytab

}
```
  Par exemple:
```
wsadmin.bat -user adminuser -password adminpwd
$AdminTask createKrbConfigFile {-krbPath y:\SPNEGO\krb5.conf -realm CN.IBM.COM -kdcHost AD.cn.ibm.com -dns cn.ibm.com -keytabPath y:\SPNEGO\merged.keytab}
```
5. Activez la connexion unique SPNEGO en configurant Kerberos dans la consoleWebSphere® Application Server Integrated Solutions Console. Suivez à cet effet les étapes de la rubrique Activation de la connexion unique pour Security® Access Manager avec SPNEGO.
6. Synchronisez le noeud et redémarrez le noeud du gestionnaire de déploiement.
  Si vous ne pouvez pas gérer le noeud Portal dans la console WebSphere® Application Server Integrated Solutions Console, synchronisez-le manuellement, puis redémarrez le noeud du gestionnaire de déploiement.
Configurez Security Access Manager sur le serveur Portal en suivant les instructions de l'article Configuration de Security® Access Manager qui correspond à votre serveur Portal.
Remarque : Pour l'intégration des connexions aux portlets, les cookies de session WebSEAL doivent être envoyés au serveur de jonction. Cette action peut être définie par l'ajout de l'option -k aux commandes qui créent une jonction.
Par exemple, sur Portal 7 :
```
server task default-webseald-TAMhost.cn.ibm.com create -t ssl -b filter -A -F C:\WASLTPA.key 
-Z password -h DMhost.cn.ibm.com -c all -f -k -j -J trailer /wpsv70

ConfigEngine.bat run-svrssl-config -Dwp.ac.impl.PDAdminPwd=password
ConfigEngine.bat validate-pdadmin-connection -DWasPassword=password -Dwp.ac.impl.PDAdminPwd=password
ConfigEngine.bat enable-tam-all -DWasPassword=password
```
Configurez la liste de contrôle d'accès (ACL) pour WebSEAL afin d'autoriser les demandes HTTP PUT. Pour cela, ajoutez cette liste à la jonction Portal.
1. Créez une ACL HCL Connections par défaut pour remplacer l'ACL WebSEAL par défaut en exécutant les commandes suivantes :
```
acl create lc3-default-acl 
acl modify lc3-default-acl set user sec_master TcmdbsvaBRlrx
acl modify lc3-default-acl set any-other Tmdrx
acl modify lc3-default-acl set unauthenticated T
acl modify lc3-default-acl set group iv-admin TcmdbsvaBRrxl
acl modify lc3-default-acl set group webseal-servers Tgmdbsrxl
```
2. Connectez l'ACL par défaut aux URL des racines des applications :
```
acl attach /WebSEAL/tam_server-WebSEAL_instance/app_root lc3-default-acl
```
  où :
  - tam_server est le nom d'hôte du serveur Security Access Manager.
  - WebSEAL_instance est le nom de l'instance du serveur WebSEAL configuré pour gérer HCL Connections. Par exemple: par défaut
  - app_root est le chemin racine vers les applications HCL Connections, notamment /activities, /blogs, /cognos, /communities, /dogear, /files, /forums, /homepage, /news, /metrics, /mobile, /moderation, /profiles, /search et /wikis.
  - lc3-default-acl est la liste de contrôle d'accès que vous avez définie. Par exemple: acl attach /WebSEAL/tam.example.com-default/activities example-default-acl. Dans ce cas, la commande est acl attach /WebSEAL/tam.example.com-default/PORTAL_VHOST_JCT example-default-acl.