Vérification d'identité sur le serveur en aval
Lorsqu'un client s'authentifie sur un serveur, le justificatif reçu est défini. Lorsque le moteur d'autorisation vérifie le justificatif afin de déterminer si l'accès est permis, il définit également le justificatif d'appel. La vérification d'identité est le justificatif d'appel qui est vérifié auprès du serveur en aval.
Lorsqu'un client s'authentifie sur un serveur, le justificatif reçu est défini. Lorsque le moteur d'autorisation vérifie le justificatif afin de déterminer si l'accès est permis, il définit également le justificatif d'appel, pour que, si la méthode Enterprise JavaBeans (EJB) appelle une autre méthode d'EJB qui se trouve sur d'autres serveurs, le justificatif d'appel puisse être l'identité utilisée pour démarrer la méthode en aval. En fonction du mode RunAs pour les beans enterprise, le justificatif d'appel est défini en tant qu'identité client d'origine, qu'identité du serveur ou en tant qu'identité différente définie. Quelle que soit l'identité définie, lorsque la vérification d'identité est activée le justificatif d'appel est vérifié dans le serveur en aval.
L'identité du justificatif d'appel est envoyé au serveur en aval dans un jeton
d'identité. De plus,
l'identité du serveur émetteur (incluant le mot de passe ou le jeton) est envoyée dans le jeton d'authentification du client lorsque l'authentification de base est activée. L'identité du serveur émetteur est envoyée par le biais d'un processus d'authentification par certification client SSL (Secure Sockets Layer) lorsque l'authentification par certificat client est activée.
L'authentification de base prévaut sur l'authentification à l'aide d'un certificat client
- L'identité du serveur émetteur transmise au serveur de réception est un jeton GSSUP (ID utilisateur et mot de passe) ou un certificat client SSL. Sous z/OS, l'ID de la tâche MVS démarrée est transmis à la place du jeton GSSUP lorsque le registre utilisateur actif est le système d'exploitation local et que l'autorisation SAF est activée.
- La confiance est établie entre le serveur émetteur et le serveur de réception en fonction de l'identité transmise.
- Lorsqu'un jeton GGSUP est transmis, la confiance est établie après vérification que l'identité du serveur émetteur figure dans la liste principale digne de confiance du serveur de réception.
- Lorsque l'ID de la tâche MVS démarrée est transmis, la confiance est établie après vérification que cet ID dispose des droits UPDATE sur le profil CB.BIND.<nom_serveur> dans la base de données SAF.
- Sous z/OS, lorsqu'un certificat client SSL est transmis, ce certificat est mappé vers un ID utilisateur Service Access Facility (SAF). La confiance est établie après vérification que cet ID dispose des droits UPDATE sur le profil CB.BIND.<nom_serveur>.
- Après avoir déterminé que le serveur émetteur se trouvait dans la liste des tiers dignes de confiance, le serveur authentifie le serveur émetteur pour garantir son identité.
- Le serveur est authentifié par comparaison de l'ID utilisateur et du mot de passe du serveur émetteur avec ceux du serveur récepteur. Si les justificatifs du serveur émetteur sont authentifiés et dignes de confiance, le serveur passe à l'étape d'évaluation du jeton d'identité.
- Le serveur de réception vérifie dans son registre des utilisateurs définis la présence de l'ID utilisateur vérifié pour collecter des justificatifs
supplémentaires pouvant servir à l'autorisation (appartenance à des groupes, par exemple). Ainsi, le registre des utilisateurs du serveur de réception doit contenir la totalité des ID utilisateurs à vérifier. Faute de quoi, la vérification d'identité est impossible. Dans un serveur avec état, cette action s'effectue une fois pour la paire serveur émetteur/serveur de réception lorsque les jetons d'identification sont identiques. Les demandes ultérieures sont effectuées via un ID de session.Remarque : Lorsque le serveur en aval ne dispose pas d'un registre des utilisateurs avec accès aux ID utilisateurs dans son référentiel, n'utilisez pas la vérification d'identité car la vérification des autorisations échouera. En désactivant la vérification d'identité, vous supprimez le besoin de vérifier les autorisations sur le serveur de réception.
Le serveur cible valide les droits d'accès du serveur émetteur afin de vérifier une identité par le certificat client. Le certificat client est mappé à un ID utilisateur SAF (Service Access Facility) en utilisant les filtres RACDCERT MAP ou des filtres RACMAP définis dans
la base de données SAF. L'ID utilisateur SAF doit disposer de l'autorisation UPDATE pour le profil CB.BIND.<optionSAFProfilePrefix>.nom_court_cluster dans la classe CBIND. Si aucun certificat client n'est envoyé, la vérification CBIND est exécutée par rapport à l'ID de tâche démarrée du serveur expéditeur.
- Nom du principal
- Nom distinctif (DN)
- Chaîne de certification
- Identité anonyme
Une fois le format de l'identité détecté et analysé, l'identité est mappée à un justificatif. Pour un jeton d'identité ITTPrincipal, celui-ci est mappé un-à-un aux zones ID utilisateur.
Pour un jeton d'identité ITTDistinguishedName, le mappage dépend du registre d'utilisateurs. Pour LDAP (Lightweight
Directory Access Protocol), le filtre de recherche configuré détermine
comment se produit le mappage. Pour le système d'exploitation local, le premier attribut
du nom distinctif, généralement identique au nom commun, est mappé à l'ID utilisateur du
registre.
Les jetons d'identité ITTDistinguishedName
et ITTCertChain sont mappés de la même manière. Les deux types de jeton d'identité utilisent un certificat mappé vers un ID utilisateur SAF à l'aide de
RACDCERT ou des fonctions de mappage équivalentes, comme les filtres RACMAP. Le mappage peut être fondé sur le nom du
sujet ou sur le nom des émetteurs.
La vérification d'identité est disponible uniquement à l'aide du protocole CSIv2
(Common Secure Interoperability Version 2).