Configuration de Security Access Manager

HCL peut être intégré à IBM® Security Access Manager pour fournir des services d'authentification, d'autorisation et pour relier le coffre des accréditations d'HCL à la fonction ISAM GSO Lockbox.

Pourquoi et quand exécuter cette tâche

Fonctions d'authentification, d'autorisation et de coffre des accréditations peuvent être configurées dans les combinaisons suivantes :
  • L'authentification peut être configurée avec ou sans les autres fonctions
  • L'intégration du coffre des accréditations peut être configurée avec ou sans les autres fonctions
  • L'autorisation ne peut être configurée sans configuration de l'authentification.

Dans le cadre de l'intégration de l'authentification, vous pouvez également configurer l'application des accès utilisateur HCL pour activer complètement les utilisateurs créés en tant qu'utilisateurs Security Access Manager. Par défaut, les utilisateurs qui sont créés dans LDAP par HCL ne sont pas des utilisateurs Security Access Manager. Cette configuration n'est nécessaire que si vous ne disposez pas d'un système de gestion des identités d'entreprise et d'un processus d'application des accès intégré à IBM® Security Access Manager, et que vous utilisez HCL comme outil de création d'utilisateur.

Important information about authentication : Pour intégrer HCL et IBM®Security Access Manager pour l'authentification, vous devez créer une ou plusieurs jonctions dans WebSEAL pointant vers HCL. A partir de HCL version 8.0, le type de jonction pris en charge dépend de votre cas d'utilisation :
Tableau 1. Cas d'utilisation pour un type de jonction

Lisez les informations suivantes pour choisir le type de jonction à créer en fonction de votre cas d'utilisation.
Cas d'utilisation Type de jonction pris en charge
Cas d'utilisation simple
Une seule instance logique HCL derrière la couche de WebSEAL, en utilisant la racine de contexte/wps par défaut. L'instance HCL peut être l'un des déploiements suivants :
  • Serveur autonome
  • Cluster unique
  • Ensemble commun d'instance de portail dans un parc de serveurs
 Une jonction transparente ou une jonction d'hôte virtuel peuvent être utilisées. Les jonctions peuvent être de type TCP ou SSL. Elles peuvent utiliser un intercepteur de relations de confiance (TAI) dans WebSphere® ou générer des jetons LTPA dans WebSEAL pour la vérification d'identité.

Toutes les URL HCL ne commencent pas par /wps. Par conséquent, si vous utilisez des jonctions transparentes, vous devez configurer plusieurs jonctions transparentes pour obtenir toutes les demandes retransmises à HCL depuis WebSEAL. Pour éviter ce problème, utilisez une jonction d'hôte virtuel unique.

Conseil : Si vous projetez de modifier la racine de contexte HCL, utilisez des jonctions d'hôte virtuel.
Autres cas d'utilisation
Tout élément autre qu'un cas d'utilisation simple.
 Le type de jonction pris en charge pour le cas général est la jonction d'hôte virtuel. Les jonctions d'hôte virtuelles peuvent être de type TCP ou SSL. Elles peuvent utiliser un intercepteur de relations de confiance (TAI) dans WebSphere® ou générer des jetons LTPA dans WebSEAL pour la vérification d'identité.
Integrating WebSEAL and HCL Portal by using virtual portals :

Des portails virtuels peuvent être définis et identifiés dans une demande entrante à l'aide d'un jeton dans l'adresse URL ou d'un nom d'hôte virtuel. Si le jeton URL est utilisé, il est placé juste après le mappage de servlet de l'URL, par exemple, le jeton portal ou myportal. Si un nom d'hôte virtuel est utilisé, le nom d'hôte d'une demande qui cible le portail virtuel possède un nom d'hôte qui est différent de celui des demandes émises vers d'autres portails virtuels ou le portail de base.

Lorsque HCL est intégré derrière WebSEAL en tant que proxy à l'aide des portails virtuels définis par le nom d'hôte virtuel, la configuration consiste à disposer d'une jonction d'hôte virtuel dans WebSEAL pour chaque portail virtuel dans HCL (un pour un dans les deux sens). En outre, le nom d'hôte de la jonction d'hôte virtuel dans WebSEAL doit être identique au nom d'hôte de portail virtuel correspondant sur WebSphere® Portal. La jonction d'hôte virtuel peut elle-même être définie via le nom d'hôte de portail virtuel identique au nom d'hôte de jonction d'hôte virtuel, ou via le nom d'hôte du portail réel ou du serveur HTTP, comme hôte de serveur dorsal (la valeur du paramètre -h sur la définition de jonction). Il est préférable d'utiliser le nom d'hôte de portail virtuel car certaines opérations (par exemple, les calculs de redirection) dépendent de la valeur de l'en-tête HOST et avec le paramètre -h dans la définition de jonction, WebSEAL affecte cette valeur à l'en-tête HOST. Si le nom d'hôte de portail virtuel est utilisé, une résolution DNS interne secondaire ou une manipulation des fichiers hosts doit être utilisée par WebSEAL pour résoudre ce nom d'hôte en adresse IP du serveur HTTP ou de l'hôte de portail.

Sélectionnez les tâches appropriées pour configurer IBM® Security Access Manager :