Single Sign-on

Die einmalige Anmeldung ist ein Authentifizierungsprozess, bei dem ein Benutzer auf mehrere Anwendungen zugreifen kann, indem er eine einzige Benutzer-ID und ein einziges Kennwort eingibt. Sie können mehrere Anwendungen so konfigurieren, dass sie für die Benutzerauthentifizierung und -autorisierung verwendet Verify werden. Die Benutzer melden sich mit ihren Verify Anmeldedaten bei den Zielanwendungen an. VerifyNach der Authentifizierung können Benutzer innerhalb der authentifizierten Sitzung auf alle Anwendungen zugreifen, für die sie berechtigt sind. Wenn die Sitzung abläuft, müssen sich die Benutzer erneut über Verify… anmelden.

Um Single Sign-On zwischen Verify und einer beliebigen Zielanwendung zu implementieren, müssen diese Konfigurationsdaten austauschen. Sie müssen die Anwendung in Verify konfigurieren und in der Zielanwendung konfigurieren Verify .

Authentifizierung und Berechtigung

Authentifizierung ist die Verifizierung der Identität eines Benutzers, indem bestätigt wird, dass der Benutzer die Person ist, die er vorgibt zu sein. Berechtigung bedeutet, einem Benutzer den Zugriff auf eine Ressource zu erteilen und zu definieren, welche Aktionen diese Person für die Ressource ausführen kann. Verify unterstützt die Authentifizierung und Autorisierung mithilfe von „ SAML “ und „ OpenID Connect “.
Tabelle 1. Vergleichsübersicht
SAML 2.0 OpenID Connect
Beschreibung

Die Security Assertion Markup Language ( SAML ) ist ein offener Standard, der Authentifizierung und Autorisierung ermöglicht.

Der Standard stellt ein Framework für den sicheren Austausch von Benutzeridentitäten zwischen einem Service-Provider und einem Identitätsprovider bereit.

OpenID Connect ist ein offenes Standardprotokoll, das die Authentifizierungsfunktionen von „ OpenID “ und die Autorisierungsfunktionen von „ OAuth2.0 “ vereint.

Der Standard stellt ein Framework für den sicheren Austausch von Benutzeridentitäten zwischen einer Relying Party und einem OpenID Connect-Provider bereit.

Anwendungsfall

Einmalige Anmeldung für Unternehmensanwendungen

Einmalige Anmeldung für Unternehmens- und Konsumentenanwendungen

Unterstützte Clienttypen
  • Webbasiert
  • Webbasiert
  • Mobil oder nativ
  • JavaScript
Datenformat XML JSON
Benutzerinformationen oder Authentifizierung gesendet über

Eine „ SAML “-Aussage.

Die Zusicherung enthält die folgenden Informationen:
  • Subjekt (Person, die sich authentifiziert hat)
  • Attribute (Informationen zu der Person)
  • Aussteller (Person, die die Zusicherung ausgestellt hat)
  • Andere Informationen zum Authentifizierungsereignis

Ein JSON Web Token (JWT), auch als ID-Token bezeichnet.

Das Token enthält die folgenden Informationen:
  • Subjekt (Person, die sich authentifiziert hat)
  • Aussteller (Person, die die Benutzeransprüche ausgestellt hat)
  • Authentifizierungsablauf
  • Attribute oder Benutzerangaben (Informationen über die Person) 1
  • Andere Informationen zum Authentifizierungsereignis
Tokens Zugriffstoken
  • ID-Token
  • Zugriffstoken. Das Zugriffstoken kann entweder eine opake Zeichenfolge sein oder im JWT-Format vorliegen.
  • Token aktualisieren
Hinweis: Die Länge der OIDC-Token unter OAuth ist nicht festgelegt. Berücksichtigen Sie beim Speichern der Zugriffs- und Aktualisierungstoken variable Längen. Wenn Sie eine maximale Speicherkapazität festlegen müssen und nicht vorhaben, in Zukunft Zugriffstoken im JWT-Format zu verwenden, sollten Sie eine Tokenlänge von mindestens 1024 Zeichen vorsehen.
Komponenten/Rollen
  • Benutzer: Die Person, die Zugriff anfordert.
  • Benutzeragent: Das Ziel der Authentifizierung des Benutzers, beispielsweise der Web-Browser.
  • Service-Provider: Die Anwendung, auf die der Benutzer zuzugreifen versucht.
  • Identitätsprovider: Der Provider, der den Benutzer authentifiziert.
  • Benutzer: Die Person, die Zugriff anfordert.
  • Benutzeragent: Das Ziel der Authentifizierung des Benutzers, beispielsweise der Web-Browser.
  • Relying Party oder Client: Die Anwendung, auf die der Benutzer zuzugreifen versucht.
  • OpenID Connect-Provider: Der Provider, der den Benutzer und den Client authentifiziert.

SAML-basierte einmalige Anmeldung

Beim Service-Provider kann es sich um eine beliebige webbasierte Anwendung handeln, die die Authentifizierung ihrer Benutzer erfordert. Sie ist der Konsument der zurückgegebenen Benutzeridentitätsinformationen.

Der Identitätsprovider verwaltet und bestätigt die Benutzeridentität.

  1. Der Benutzer fordert Zugriff auf eine geschützte Ressource des Service-Providers über einen Benutzeragenten an.
  2. Der Service-Provider sendet eine Benutzerauthentifizierungsanforderung, indem er den Benutzeragenten zum Identitätsprovider umleitet.
  3. Der Identitätsanbieter überprüft die Identität des Benutzers und generiert eine „ SAML “-Assertion, die die Identität des Benutzers bestätigt.
  4. Der Identitätsanbieter bündelt die Assertion in seiner „ SAML “-Authentifizierungsantwort an den Dienstanbieter.

OpenID Connect-basierte einmalige Anmeldung

Die Connect“-Vertrauende Partei von „ OpenID “ kann jede Anwendung sein, die eine Authentifizierung ihrer Benutzer erfordert. Sie ist der Konsument der zurückgegebenen Benutzeridentitätsinformationen.

Der OpenID Connect-Provider authentifiziert den Benutzer über seinen Berechtigungsendpunkt und authentifiziert den Client über seinen Tokenendpunkt.
  1. Der Benutzer fordert Zugriff auf eine geschützte Ressource der Relying Party über einen Benutzeragenten an.
  2. Die Relying Party sendet eine Benutzerauthentifizierungsanforderung, indem der Benutzeragent zum OpenID Connect-Provider umgeleitet wird.
  3. Der OpenID Connect-Provider verifiziert, ob der Benutzer über eine gültige Sitzung verfügt. Ist dies nicht der Fall, fordert der OpenID Connect-Provider eine Benutzeranmeldung an und authentifiziert den Benutzer über den Berechtigungsendpunkt.
  4. Abhängig vom Berechtigungserteilungstyp kann der Berechtigungsendpunkt des Identitätsproviders eine Authentifizierungsantwort an die Relying Party senden, die eines der folgenden Elemente enthält:
    • Diese Autorisierung kann dann von einem Client in einer Anfrage übermittelt werden, zusammen mit einem Autor isierungscode², den die vertrauende Partei an einen Token-Endpunkt übermittelt, um im Gegenzug ein ID-Token, ein Zugriffstoken oder ein Aktualisierungstoken zu erhalten.
    • Ein ID-Token und ein Zugriffstoken.

      Das ID-Token oder das Aktualisierungstoken enthält die Benutzeransprüche und die Signatur, die zum Aufbau der Benutzersitzung verwendet werden.

    • Ein QR-Code, ein Benutzercode und eine URL.
    • Impliziter Fluss. Es führt die Authentifizierung und Autorisierung durch und gibt dem Client in seiner Antwort direkt ein ID-Token und ein Zugriffstoken zurück.
    Hinweis: Der implizite Datenfluss des Anbieters „ OpenID Connect“ unterstützt den Token-Endpunkt nicht.
1 Diese Angaben sind Aussagen über den Nutzer, denen vertraut werden kann, wenn der Empfänger des Tokens dessen Signatur überprüfen kann. Sie dienen dazu, der Clientanwendung Benutzerdetails, wie E-Mail-Adresse und Name, für die Zustimmung erteilt wurde, zur Verfügung zu stellen.
2 ein Zwischenzertifikat, das die Berechtigung enthält.