IBM Verify Bridge

Die IBM® Verify Bridge Komponente ermöglicht IBM den Cloud-Zugriff auf Benutzerattribute und die Authentifizierung, die über die lokal installierte „ LDAP “, „ Active Directory “ oder eine benutzerdefinierte Datenbank des Kunden gesteuert werden.

Einführung

Die Komponente Verify Bridge ermöglicht den Zugriff auf die Authentifizierung und Benutzerattribute von lokalen Datenbanken ( LDAP ), „ Active Directory “ oder benutzerdefinierten Datenbanken aus IBM Verify den Komponenten.

Die Hauptverbindung zwischen dem Verify Bridge und dem IBM Verify Mieter erfolgt entweder über einen HTTP oder einen HTTPS Long-Poll. Diese Verbindung wird von der Verify Bridge Bridge initiiert und erfordert ein autorisiertes Zugriffstoken, das die Bridge beim Start abruft und regelmäßig aktualisiert. Verify BridgeNachdem die Long-Poll-Verbindung hergestellt wurde, fließt der Datenverkehr von Verify zu.

Komponentenübersicht

Das folgende Diagramm veranschaulicht die Hauptkomponenten der Verify Bridge Architektur.

Die Abbildung zeigt alternative Abläufe für Identitätsquellen, die auf „ LDAP “ basieren, sowie für solche, die nicht auf „ LDAP “ basieren.
Workloads
Workloadanforderungen werden an jede verbundene Instanz des Agenten gesendet, die die Identitätsquelle darstellt. Dies bietet eine hohe Verfügbarkeit (HA) und eine skalierbare Leistung. Es kann jeder Agent ausgewählt sein.
LDAP-Agent Identitätsquelle 1
Pro Identitätsquelle können mehrere Instanzen des Bridgeagenten implementiert werden. Mehrere Instanzen ermöglichen einem Cluster von Bridgeagenten, Serviceanforderungen und Workloads für eine bestimmte Identitätsquelle zu verarbeiten.
LDAP-Quelle 1 (Replikat2)
Jede Bridgeagenteninstanz muss die Verbindung zu demselben Repository für externe Daten oder einem Replikat des Repositorys für externe Daten herstellen können. Jede primäre und Replikats-URL wird als Teil der Verbindungsinformationen des Agenten konfiguriert. Verbindungsversuche werden in der in der Konfiguration angegebenen Reihenfolge durchgeführt.
Für dieses Diagramm gilt Folgendes:
  1. Die Abläufe und Kästchen in dem Kästchen für Verify stellen nur Konzepte dar.
  2. Für eine Identitätsquelle können mehrere Instanzen des Bridgeagenten bereitgestellt werden. Aufgrund dessen wird ein Cluster von Bridgeagenten für Serveranforderungen und Workloads für eine Identitätsquelle aktiviert. Jede Bridgeagenteninstanz muss die Verbindung zu demselben Repository für externe Daten oder einem Replikat des Repositorys für externe Daten herstellen können.
Hinweis:
  • Die LDAP-TLS-Serverzertifikatsvalidierung wird jetzt durchgesetzt, wenn der Host mithilfe einer IP-Adresse angegeben wird. Nach dem Upgrade kann die bestehende Verwendung von TLS und der IP-Adresse fehlschlagen. Zwei Optionen sind für die Benutzer verfügbar, die von dieser Änderung betroffen sind:
    • "LdapCertHostName" "{your cert host name}"Geben Sie den Hostnamen des Zertifikats für den „ LDAP “-Server mithilfe des optionalen Konfigurationselements an.
    • Ändern Sie den LDAP-URI so, dass der Hostname für das LDAP-Serverzertifikat verwendet wird. Wenn eine temporäre sofortige Problemumgehung erforderlich ist, bis eine Lösung ausgewählt wird, setzen Sie die optionale Konfiguration "InsecureSkipVerify" auf "true".
  • Ab Version 1.0.9 werden keine Zertifikate mehr akzeptiert, die auf dem traditionellen Feld Allgemeiner Name basieren. Von den Zertifikaten muss stattdessen SAN (Subject Alternative Name) verwendet werden. Wenn die Hostnamensidentifikation im traditionellen Feld für den allgemeinen Namen verwendet werden muss, legen Sie die Umgebungsvariable GODEBUG='x509ignoreCN=0' für den Windows onprem.exe-Prozess fest oder übergeben diese an das Docker-Image.

Unterstützte Software

Betriebssysteme
  • Windows Server 2016
  • Windows Server 2019
  • Windows Server 2012 R2
  • Windows Server 2022
  • Windows Server 2025
  • Linux Systeme, die die „ Docker “-Engine unterstützen 19.03.0 oder höher