Mappage d'identités pour l'autorisation sur des serveurs de domaines multiples
Le mappage d'identité est un mappage un à un de l'identité de l'utilisateur entre deux serveurs permettant la prise de décisions d'autorisation correcte par les serveurs en aval. Le mappage d'identité est nécessaire lorsque l'intégration de serveurs est requise, mais les registres d'utilisateurs sont différents et ne sont pas partagés entre les systèmes.
A propos de cette tâche
Dans la plupart des cas, les demandes sont transmises en aval entre deux serveurs faisant partie du même domaine de sécurité. Dans WebSphere® Application Server, deux serveurs membres de la même cellule sont également membres du même domaine de sécurité. Il utilisent le même registre d'utilisateurs et les mêmes clés LTPA (Lightweight Third Party Authentication) pour le chiffrement du jeton. Ces deux similarités garantissent que le jeton LTPA, entre autres attributs utilisateur, transmis entre les deux serveurs, puisse non seulement être déchiffré et validé, mais également que l'identité utilisateur contenue dans le jeton puisse être mappée aux attributs reconnus par le moteur d'autorisation.
La configuration la plus fiable recommandée implique deux serveurs dans la même cellule. Il est cependant parfois nécessaire d'intégrer plusieurs systèmes qui ne peuvent pas utiliser le même registre utilisateur. Lorsque les registres d'utilisateurs diffèrent entre deux serveurs, le domaine de sécurité ou le domaine du serveur cible ne correspond pas au domaine de sécurité du serveur d'origine.
WebSphere Application Server permet d'effectuer un mappage avant l'envoi de la demande ou la transmission des justificatifs de sécurité existants au serveur cible. Les justificatifs sont mappés en entrée avec la spécification que le domaine cible est digne de confiance.
Une solution alternative au mappage consiste à envoyer l'identité de l'utilisateur sans le jeton ou le mot de passe au serveur cible sans réellement mapper l'identité. L'utilisation de l'identité de l'utilisateur repose sur la relation de confiance entre deux serveurs. Utilisez le mécanisme de vérification d'identité de CSIv2 (Common Secure Interoperability Version 2). Si cette fonction est activée, le serveur envoie simplement le certificat X.509, le nom du principal ou le nom distinctif en fonction de ce qu'a utilisé le client d'origine pour l'authentification initiale. Pendant la vérification d'identité CSIv2, la sécurisation est établie entre les serveurs WebSphere Application Server.
Pour que l'évaluation d'identité puisse être effectuée, l'identité de l'utilisateur doit être présente dans le registre d'utilisateurs cible. Ce processus peut également permettre l'interopérabilité entre d'autres serveurs d'applications compatibles Java™ 2 Platform, Enterprise Edition (J2EE) version 1.4 et versions ultérieures. Si la vérification d'identité est configurée à la fois sur le serveur d'origine et sur les serveurs cibles, WebSphere Application Server utilise toujours cette méthode d'authentification, même lorsque les deux serveurs se trouvent dans le même domaine de sécurité. Pour plus d'informations sur la vérification d'identité CSIv2 , voir Vérification d'identité sur le serveur en aval.
- Vous connaissez l'identité de l'utilisateur du justificatif existant car elle provient du registre d'utilisateurs du serveur d'origine.
- Il n'y a pas lieu de partager les clés LTPA (Lightweight Third Party Authentication) avec l'autre domaine cible car vous ne mappez pas l'identité aux justificatifs LTPA. En général, vous mappez l'identité à un ID utilisateur et à un mot de passe présents dans le registre d'utilisateurs du domaine cible.
Lorsque vous avez besoin d'un mappage entrant, peut-être en raison des capacités de mappage du serveur entrant, vous devez vous assurer que les deux serveurs ont les mêmes clés LTPA afin d'accéder à l'identité de l'utilisateur. En général, dans les communications sécurisées entre serveurs, un jeton LTPA est transmis dans le rappel WSCredTokenCallback à des fins d'authentification du client. Il existe une méthode permettant d'ouvrir le jeton LTPA, lorsque celui-ci est valide, et d'accéder à l'ID unique de l'utilisateur pour que le mappage puisse être effectué. Pour plus d'informations, voir Configuration du mappage des identités entrantes. Dans d'autres cas, comme la vérification d'identité, vous pouvez recevoir un nom d'utilisateur dans le rappel NameCallback de la configuration de connexion entrante qui vous permet d'activer l'identité.
Les points suivants sont traités dans cette section :
Procédure
- Configuration du mappage d'identités entrantesPour le mappage d'identité entrantes, vous pouvez écrire un module de connexion personnalisé et configurer un serveur WebSphere Application Server de façon à exécuter en premier ce module dans les configurations de connexion système. Prenez en compte les étapes suivantes lorsque vous écrivez votre module de connexion personnalisé: Configuration du mappage des identités entrantes.
- Configuration du mappage d'identités sortantes vers un domaine cible différentPar défaut, lorsque WebSphere Application Server effectue une demande sortante d'un serveur vers un serveur d'un autre domaine de sécurité, la demande est rejetée. Cette rubrique détaille les solutions permettant à un serveur d'envoyer des demandes sortantes à un serveur cible d'un autre domaine. Pour plus d'informations, voir Configuration du mappage d'identité sortante dans un domaine cible différent