Remarques relatives à la planification des jonctions WebSEAL

Elle fait office de point d'accès unique à un réseau d'applications Web.

Une jonction est une connexion HTTP ou HTTPS entre un serveur WebSEAL frontal et un serveur d'application Web dorsal. WebSEAL effectue des contrôles d'authentification sur toutes les demandes de ressources avant de transmettre ces demandes via une jonction au serveur dorsal.

A compter de la version 8.0 d'HCL, les types de jonction pris en charge entre le serveur WebSEAL frontal et un serveur HCL dorsal sont les suivants :

Jonctions d'hôte virtuel - Ce type de jonction est généralement pris en charge pour tous les cas d'utilisation.
Jonctions transparentes - La prise en charge des jonctions transparentes avec HCL est limitée à un cas d'utilisation simple. Par exemple, une instance logique d'HCL qui utilise la racine de contexte par défaut /wps. L'instance logique peut être un serveur ou un cluster, ou encore un ensemble de noeuds de parc de serveurs qui exécute une instance logique unique ou un site Web Portal, lequel peut inclure des portails virtuels. Tout cas de figure plus complexe que celui-ci nécessite d'utiliser des jonctions d'hôte virtuel.

Les éditions antérieures prenaient en charge l'utilisation de jonctions classiques WebSEAL non transparentes, mais cette configuration n'est plus prise en charge par HCL 8.0 ou version ultérieure. Avec la prolifération des URL HCL, la jonction d'hôte virtuel est désormais la méthode la plus efficace pour faire fonctionner un serveur HCL derrière un proxy WebSEAL. Toutes les discussions relatives au chiffrement, au TAI (Trust Association Interceptor) par rapport à LTPA et à d'autres options de configuration restent applicables. La différence réside dans le type global de jonction, qui détermine la manière dont la jonction est visible pour les utilisateurs.

Une jonction traditionnelle non transparente possède un jeton dans l'URL qui correspond à la jonction dans WebSEAL. Par exemple, l'URL peut être http://webseal.hostname.yourco.com/junction1/wps/myportal. Une jonction transparente utilise un jeton existant dans l'URL pour identifier la jonction. Par exemple, elle utilise le jeton /wps dans /wps/myportal. Le problème avec ces deux méthodes est que HCL possède un grand nombre d'URL et qu'elles ne commencent pas toutes par /wps. Il est également difficile de les configurer de sorte qu'elles utilisent un préfixe cohérent.

Les jonctions d'hôte virtuel utilisent un nom d'hôte virtuel pour identifier la jonction. Pour identifier la jonction, le nom d'hôte pourrait être junction1.webseal.hostname.yourco.com. Cette jonction est donnée à titre d'exemple uniquement ; vous pouvez utiliser n'importe quel nom d'hôte adapté à votre domaine. La jonction est ensuite définie dans WebSEAL de sorte qu'elle utilise le nom d'hôte entrant, plutôt qu'un jeton d'URL, pour identifier la jonction et les serveurs dorsaux correspondants.

Dans la configuration décrite ici, le composant WebSEAL de Security Access Manager gère l'authentification des utilisateurs. Un intercepteur de relation de confiance (TAI) est utilisé par WebSphere® Application Server et HCL pour accepter l'identité de l'utilisateur comme étant certifiée par WebSEAL.

Pour sécuriser correctement le système WebSphere® Application Server et HCL contre d'éventuelles attaques, l'intercepteur de relations de confiance doit authentifier le serveur WebSEAL. Ainsi, seules les demandes présentées de manière légitime par l'intermédiaire du serveur WebSEAL soient acceptées. Il existe plusieurs manières de configurer cette authentification entre WebSEAL et le TAI dans WebSphere® Application Server. Vous pouvez choisir entre les différentes méthodes de configuration en fonction du niveau d'effort et des performances que vous voulez placer dans la sécurisation de votre réseau. Les décisions que vous prenez déterminent comment vous configurez les jonctions entre le serveur WebSEAL et HCL.

Remarque : Par défaut, l'interface de configuration XML ne peut pas accéder à HCL via une jonction WebSEAL. Pour permettre à l'interface de configuration XML d'accéder à HCL via une jonction WebSEAL, utilisez Security Access Manager pour déprotéger l'adresse URL de configuration (/wps/config) dans la jonction. Consultez la documentation de WebSEAL pour obtenir des instructions spécifiques sur la définition d'adresses URL distinctes dans la jonction et sur l'attribution de listes de contrôle d'accès (ACL) à ces URL. Une fois l'adresse URL de configuration définie comme non protégée, seul HCL applique le contrôle d'accès à cette adresse URL. Les autres ressources qui sont protégées dans la jonction WebSEAL (par exemple, l'URL wps/myportal) restent protégées par WebSEAL.

Authentification de base utilisant une jonction non cryptée

L'identité de l'utilisateur doit être transmise au TAI dans un en-tête appelé iv-user. L'en-tête est inséré par WebSEAL dans la demande envoyée par WebSEAL aux serveurs WebSphere® Application Server et HCL. L'option de création de jonction permettant de transmettre l'identité de l'utilisateur est -c iv-user. Alors que WebSEAL peut être configuré pour transmettre l'identité de l'utilisateur d'autres façons, l'en-têteiv-user est la seule supportée par le TAI.

Configurations de jonctions avancées

Pour plus de détails et d'options sur la configuration des jonctions entre WebSEAL et WebSphere® Application Server et HCL, notamment d'autres options de spécification de l'identité du serveur WebSEAL, consultez le guide d'administration et de WebSEAL et la documentation du serveur HTTP que vous utilisez avec WebSphere®Application Server.

Il est possible de configurer les jonctions entre WebSEAL et WebSphere® Application Server et HCL pour qu'elles soient chiffrées ou non. Les jonctions chiffrées améliorent la sécurité, car elles permettent de faire en sorte que personne ne puisse écouter clandestinement les informations échangées entre WebSEAL, WebSphere® Application Server et HCL. Néanmoins, elles requièrent une configuration supplémentaire de l'administration afin de permettre le déplacement des certificats de signature nécessaires entre les systèmes ; elles ont aussi un coût en termes de performances. Si vous n'avez pas l'assurance absolue que votre réseau, qui est situé entre les pare-feu, est sécurisé contre les tentatives d'accès non autorisé et la surveillance, vous devez utiliser des jonctions chiffrées entre WebSEAL et WebSphere® Application Server/HCL. Si vous n'avez pas l'assurance absolue que votre réseau est sécurisé contre les tentatives d'accès non autorisé et la surveillance, particulièrement du trafic au travers d'un pare-feu intérieur, vous devez utiliser des jonctions chiffrées entre WebSEAL et WebSphere® Application Server/HCL.

La configuration de la jonction WebSEAL-WebSphere® Application Server/HCL sur SSL requiert la configuration de WebSphere® Application Server et du serveur HTTP qui est utilisé par WebSphere®Application Server pour accepter le trafic SSL entrant et acheminer ce dernier correctement vers WebSphere®Application Server et HCL. Cette opération comprend l'importation des certificats de signature nécessaires au moins dans le magasin des clés de certificats WebSEAL, et éventuellement dans le magasin des clés de certificats du serveur HTTP.

Si vous choisissez d'utiliser des jonctions cryptées entre WebSEAL et WebSphere® Application Server et HCL, vous pouvez choisir de faire identifier et s'auto-authentifier WebSEAL auprès de WebSphere® Application Server et du TAI en utilisant son propre certificat du client. Dans ce cas, vous pouvez configurer le TAI afin qu'il ne valide plus le serveur WebSEAL, en se reposant sur la connexion SSL mutuelle pour fournir une identité fiable au serveur WebSEAL.

Si vous choisissez de ne pas utiliser de certificats côté client pour identifier le serveur WebSEAL ou que vous choisissez de ne pas utiliser de jonction SSL, vous pouvez l'identifier auprès du TAI à l'aide d'un en-tête d'authentification de base (BA). Dans ce cas, un mot de passe est placé dans l'en-tête BA et sera également configuré dans le TAI. Cette action représente un "secret partagé" que seul le TAI et le serveur WebSEAL connaissent, qui permet au TAI d'être sûr qu'il s'agit du serveur WebSEAL qui déclare l'identité de l'utilisateur et qu'il peut s'y fier. Dans ce cas, l'utilisation d'une jonction SSL fournit une sécurité supplémentaire en protégeant cet en-tête BA de toute surveillance, mais le TAI continue à se baser sur l'en-tête BA pour identifier le serveur WebSEAL.

Pour configurer la jonction en vue de l'utilisation de l'en-tête d'authentification de base pour identifier le serveur WebSEAL, utilisez l'option -b supply dans la commande de création de jonction. WebSEAL va ainsi créer l'en-tête BA à l'aide de l'ID de l'utilisateur (qui est ignoré par le TAI au bénéfice de l'en-tête iv-user) et du mot de passe configuré dans WebSEAL dans le fichier webseald-instance.conf, propriété basicauth-dummy-passwd. Le mot de passe contenu dans le fichier webseald-instance.conf doit correspondre au mot de passe de l'ID spécifié dans la propriété com.ibm.websphere.security.webseal.loginid des paramètres de démarrage du TAI dans la WebSphere® Integrated Solutions Console. Par exemple, si vous spécifiez com.ibm.websphere.security.webseal.loginid=mistered dans les paramètres de démarrage du TAI, et si le mot de passe pour mistered est wilbur, vous devez alors indiquer wilbur dans la propriété basicauth-dummy-passwd qui figure dans le fichier webseald-instance.conf sur le serveur WebSEAL.