OAuth 2.0-Authentifizierung über MID-Server mit externem Anmeldeinformationsspeicher

  • Freigeben Version: Xanadu
  • Aktualisiert 1. August 2024
  • 1 Minute Lesedauer

    • Speichern Sie die OAuth 2.0-Anmeldeinformationen – Client-ID und Clientschlüssel – im Tresor CyberArk anstelle der Instanz ServiceNow. MID-Server ruft die Anmeldeinformationen aus dem Tresor CyberArk ab, wenn dies zum Abrufen des OAuth-Tokens erforderlich ist. Das Token wird auf dem MID Server gespeichert und bei Ablauf automatisch aktualisiert.

    Das Produkt CyberArk Application Identity Management (AIM) nutzt die Lösung für die Sicherheit privilegierter Konten, um zu verhindern, dass Anwendungspasswörter eingebettet in Anwendungen, Skripts oder Konfigurationsdateien gespeichert werden, und ermöglicht die zentrale Speicherung, Protokollierung und Verwaltung dieser Passwörter in der CyberArk Tresor. Sie können den Tresor CyberArk so konfigurieren, dass OAuth 2.0-Anmeldeinformationen anstatt direkt in einem ServiceNow -Anmeldeinformationsdatensatz gespeichert werden. Weitere Informationen zu CyberArk finden Sie unter CyberArk Integration des Anmeldeinformationsspeichers.

    Architektur der OAuth 2.0-Authentifizierung der MID-Server -Anforderung

    Sie besteht aus zwei Teilen: der Instanz ServiceNow und der Umgebung, in der der AIM-Client (Application Identity Manager) und der MID Server konfiguriert werden. Beispiele für Umgebungen sind die Cloud oder eine Kundenumgebung.

    MID-Server und der Application Identity Manager (AIM) -Client müssen in derselben Umgebung konfiguriert sein, und Application Identity Manager (AIM) muss für die Interaktion mit dem externen Tresor CyberArk konfiguriert sein. Der externe Tresor CyberArk kann in der gleichen Umgebung wie der MID-Server und Application Identity Manager (AIM) oder in einer anderen Umgebung gehostet werden.

    Die Instanz ServiceNow verwaltet Anmeldeinformations-IDs, die bestimmten OAuth 2.0-Anmeldeinformationen zugeordnet sind, die im Tresor CyberArk gespeichert sind. Vor dem Senden einer OAuth-Token-Anforderung ruft der MID-Server den Bezeichner der Anmeldeinformationen von der Instanz ab und verwendet dann eine vom Kunden bereitgestellte JAR-Datei, um den Bezeichner an den AIM-Client zu senden. Der AIM-Client sendet die Anforderung an Tresor CyberArk. Der Tresor CyberArk sendet die OAuth 2.0-Anmeldeinformationen über den AIM-Client an den MID-Server zurück. Nach dem Empfang der OAuth 2.0 -Anmeldeinformationensendet der MID-Server die OAuth-Token-Anforderung an den Autorisierungsserver des Drittanbieters. Die Tokenanforderung enthält Informationen wie den Client und den geheimen Clientschlüssel, den CyberArk speichert, den OAuth-Bereich und die Token-URL, die die Instanz speichert. Nachdem der Autorisierungsserver das OAuth-Token ausgegeben hat, speichert der MID-Server das Token im Cache.
    Hinweis:
    Diese Funktion unterstützt den Client-Anmeldeinformations-Gewährungstyp.
    Die Abbildung zeigt den Authentifizierungsprozess der MID-Server-Anforderung.
    Hinweis:
    Es wird davon ausgegangen, dass der Autorisierungsserver der Drittpartei und der Tresor CyberArk im Kundennetzwerk gehostet werden.

    MID-Server-Anforderungsauthentifizierungsprozess.