IBM Verify Bridge
Ce IBM® Verify Bridge composant permet IBM d'accéder via le cloud aux attributs des utilisateurs et aux données d'authentification gérées par l' LDAP sur site, l' Active Directory ou la base de données personnalisée du client.
Introduction
Cette fonctionnalité Verify Bridge permet d'accéder à l'authentification via LDAP sur site, Active Directory ou une base de données personnalisée, ainsi qu'aux attributs utilisateur à partir IBM Verify des composants.
La connexion principale entre le Verify Bridge et le IBM Verify locataire utilise soit une requête « HTTP », soit une requête « HTTPS » de type Long-Poll. Cette connexion est établie par le Verify Bridge et nécessite un jeton d'accès autorisé, que le Bridge obtient au démarrage et actualise régulièrement. Une fois la connexion « long-poll » établie, le trafic circule de Verify vers le Verify Bridge.
Présentation du composant
Le schéma suivant présente les principaux composants de l'architecture Verify Bridge .
- Charges de travail
- Les demandes de charge de travail sont envoyées à toute instance connectée de l'agent représentant la source d'identité. Cela permet de bénéficier d'une haute disponibilité (HA) et des performances évolutives. Tout agent est sélectionné.
- Source1 d'identité de l'agent LDAP
- Plusieurs instances de l'agent de pont (Bridge Agent) peuvent être déployées par source d'identité. Plusieurs instances permettent à un cluster d'agents de pont (Bridge Agent) de traiter les demandes et les charges de travail pour une source d'identité donnée.
- Source LDAP 1 (Replica2)
- Chaque instance d’agent de pont (Bridge Agent) doit pouvoir se connecter au même référentiel de données externe réel ou à une réplique de ce dernier. Chaque URL principale et de réplique est configurée dans le cadre des informations de connexion de l'agent. Les tentatives de connexion sont effectuées dans l'ordre indiqué dans la configuration.
- Les flux et les cases illustrés dans la zone Verify sont conceptuels uniquement.
- Plusieurs instances de l'agent de passerelle peuvent être déployées pour une source d'identité. Cette possibilité permet à un cluster d'agents de passerelle de traiter les demandes et les charges de travail du serveur pour une source d'identité. Chaque instance de l'agent de passerelle doit pouvoir se connecter au référentiel de données externe réel ou à une réplique de ce dernier.
- La validation de certificat du serveur TLS LDAP est désormais appliquée lorsque l'hôte est spécifié à l'aide d'une adresse IP. Après la mise à niveau, l'utilisation existante de TLS et de l'adresse IP risque de ne pas fonctionner. Deux options sont disponibles pour les utilisateurs affectés par ce changement :
"LdapCertHostName" "{your cert host name}"Indiquez le nom d'hôte du certificat du serveur LDAP à l'aide de l'élément de configuration facultatif.- Modifiez l'URI LDAP pour utiliser le nom d'hôte du certificat du serveur LDAP. Si un travail temporaire immédiat est requis jusqu'à ce qu'une solution soit choisie, définissez la configuration facultative
"InsecureSkipVerify"sur"true".
La version 1.0.9 et ultérieure n'accepte plus les certificats qui dépendent de la zone Nom usuel existante. Les certificats doivent utiliser SAN (nom alternatif de sujet) à la place. Si l'identification du nom d'hôte de la zone Nom commun existant doit être utilisée, définissez la variable d'environnement
GODEBUG='x509ignoreCN=0'pour le processus Windows onprem.exe ou transmettez celle-ci dans l'image Docker.
Logiciels pris en charge
- Systèmes d'exploitation
- Windows Server 2016
- Windows Server 2019
- Windows Server 2012 R2
- Windows Server 2022
- Windows Server 2025
- Linux systèmes prenant en charge le moteur d' Docker 19.03.0 ou une version ultérieure