SAML 2.0, OpenID Connect und WS-Federation Bridge

FoxIDs kann als Protokoll-Bridge zwischen SAML 2.0, OpenID Connect / OAuth 2.0 und WS-Federation dienen. Dadurch kann eine Anwendung ein Identitätsprotokoll weiterverwenden, während der externe Identity Provider oder die Partneranwendung ein anderes Protokoll nutzt.

Die Bridge ist keine separate Komponente, die installiert werden muss. Sie ist das normale FoxIDs-Modell: Benutzer melden sich über eine Authentifizierungsmethode an, und FoxIDs stellt die Antwort aus, die von der application registration benötigt wird. Wenn die beiden Seiten unterschiedliche Standards verwenden, übernimmt FoxIDs Protokollübersetzung, Claim Mapping, Tokenerstellung und Sign-in-Routing.

Manche Teams beschreiben dies als protocol translation, SAML zu OIDC Übersetzung, token translation, identity broker oder federation broker. In FoxIDs beschreiben diese Begriffe dasselbe Konfigurationsmodell, aber das Design sollte weiterhin als identity trust Grenze geprüft werden. Das wichtige Ergebnis sind nicht nur übersetzte Nachrichten oder Tokens, sondern ein konsistenter Anwendungsvertrag, issuer, audience, claims und Logout-Verhalten über die verbundenen Standards hinweg.

Verwenden Sie die Bridge, wenn:

  • Eine Anwendung bereits OpenID Connect unterstützt und Benutzer über einen SAML 2.0- oder WS-Federation Identity Provider anmelden muss.
  • Eine SAML 2.0- oder WS-Federation-Anwendung einen OpenID Connect Identity Provider verwenden muss.
  • Eine Legacy-WS-Federation- oder SAML 2.0-Anwendung ohne Änderung der Anwendung mit einer modernen OpenID Connect-Identitätsplattform verbunden werden soll.
  • Mehrere Anwendungen derselben FoxIDs-Umgebung vertrauen sollen, obwohl sie unterschiedliche Standards verwenden.

Federated Identity Management (FIM) verbindet Identitäten über Domänen hinweg. Single Sign-On (SSO) ermöglicht Benutzern den Zugriff auf Anwendungen, ohne sich erneut anzumelden. FoxIDs unterstützt beides, und die Bridge macht FIM und SSO über Protokollgrenzen hinweg möglich.

So funktioniert die Bridge

OpenID Connect, SAML 2.0 und WS-Federation lösen viele der gleichen Identitätsaufgaben, unterscheiden sich aber bei Nachrichten, Tokens, Metadaten, Zertifikaten und Claim-Formaten.

  • OpenID Connect baut auf OAuth 2.0 auf und wird häufig von modernen Web-, Mobile- und API-basierten Anwendungen verwendet. Es nutzt JSON Web Tokens (JWTs) als Identity Tokens und Access Tokens.
  • SAML 2.0 ist XML-basiert und wird breit für enterprise browserbasiertes SSO eingesetzt. Es nutzt SAML Assertions und XML-Signaturen.
  • WS-Federation ist XML-basiert und wird häufig von Enterprise- und Legacy-Webanwendungen verwendet. Es nutzt typischerweise SAML 1.1- oder SAML 2.0-Tokens in WS-Federation Sign-in-Antworten.

FoxIDs verbindet diese Standards, indem es auf beiden Seiten der Verbindung als vertrauenswürdige Partei agiert:

  • Gegenüber dem externen Identity Provider wird FoxIDs als Authentifizierungsmethode konfiguriert.
  • Gegenüber der Anwendung wird FoxIDs als application registration konfiguriert.
  • Intern stellt FoxIDs Claims als JWT Claims dar und mappt bei Bedarf zwischen JWT Claims und SAML Claims.
  • Die Anwendung erhält die Protokollantwort, die sie bereits versteht.

Es gibt keine Anforderung, dass eingehendes und ausgehendes Protokoll identisch sein müssen. Eine OpenID Connect-Anwendung kann eine SAML 2.0-Authentifizierungsmethode verwenden. Eine SAML 2.0-Anwendung kann eine OpenID Connect-Authentifizierungsmethode verwenden. WS-Federation kann ebenfalls auf beiden Seiten verwendet werden.

Eine Bridge konfigurieren

Eine Bridge wird konfiguriert, indem eine Authentifizierungsmethode mit einer application registration in derselben Umgebung kombiniert wird.

  1. Konfigurieren Sie den upstream Identity Provider als Authentifizierungsmethode:
  2. Konfigurieren Sie die Anwendung als application registration:
  3. Wählen Sie in der application registration die Authentifizierungsmethode aus, die die Anmeldung verarbeiten soll.
  4. Wenn mehr als eine Authentifizierungsmethode verfügbar ist, kann die Anwendung eine Methode direkt auswählen, oder der Benutzer kann auf einer home realm discovery (HRD)-Seite wählen.
  5. Prüfen Sie Claim Mappings, Zertifikate, Metadaten und Logout-Verhalten für die Standards, die auf beiden Seiten verwendet werden.

Die wichtigste Konfigurationsentscheidung ist daher keine spezielle Bridge-Einstellung. Es ist die Zuordnung zwischen Authentifizierungsmethode und application registration.

SAML 2.0 zu OpenID Connect

Diese Bridge ist häufig, wenn eine Anwendung bereits OpenID Connect unterstützt, aber die Organisation oder der Partner-Identity Provider nur SAML 2.0 unterstützt.

Konfigurieren Sie den externen IdP als SAML 2.0-Authentifizierungsmethode. Konfigurieren Sie die Anwendung als OpenID Connect application registration und wählen Sie die SAML 2.0-Authentifizierungsmethode aus.

Wenn die Anwendung eine OpenID Connect Sign-in-Anfrage sendet, leitet FoxIDs den Benutzer zum externen SAML 2.0 IdP weiter. Die SAML 2.0-Antwort wird validiert, SAML 2.0 Claims werden auf JWT Claims gemappt, und FoxIDs gibt eine OpenID Connect-Antwort an die Anwendung zurück.

Bridge SAML 2.0 zu OpenID Connect

Lesen Sie SAML zu OIDC Bridge für OpenID Connect Anwendungen, um mehr über Architektur, Claim-Design, Migration und Produktionsreife zu erfahren.

OpenID Connect zu SAML 2.0

Diese Bridge ist nützlich, wenn eine SAML 2.0-Anwendung einen modernen OpenID Connect Identity Provider verwenden soll.

Konfigurieren Sie den externen Provider als OpenID Connect-Authentifizierungsmethode. Konfigurieren Sie die Anwendung als SAML 2.0 application registration und wählen Sie die OpenID Connect-Authentifizierungsmethode aus.

Wenn die SAML 2.0-Anwendung eine SAML 2.0 Authn Request sendet, leitet FoxIDs den Benutzer zum OpenID Provider (OP) weiter. Die OpenID Connect-Antwort wird validiert, JWT Claims werden auf SAML 2.0 Claims gemappt, und FoxIDs gibt eine SAML 2.0-Antwort an die Anwendung zurück.

Bridge OpenID Connect zu SAML 2.0

FoxIDs unterstützt Bridging für Sign-in, Logout und Single Logout zwischen SAML 2.0 und OpenID Connect.

WS-Federation Bridge-Szenarien

WS-Federation funktioniert nach demselben Modell wie die anderen Standards. Es kann als Authentifizierungsmethode konfiguriert werden, wenn der externe Identity Provider ein WS-Federation Security Token Service (STS) ist, und als application registration, wenn die Anwendung eine WS-Federation Sign-in-Antwort erwartet.

Typische WS-Federation Bridge-Szenarien sind:

  • WS-Federation IdP zu OpenID Connect-Anwendung.
  • OpenID Connect IdP zu WS-Federation-Anwendung.
  • WS-Federation IdP zu SAML 2.0-Anwendung.
  • SAML 2.0 IdP zu WS-Federation-Anwendung.

Dies ist nützlich für AD FS-Ersatzszenarien, ältere ASP.NET-Anwendungen, SharePoint, Dynamics und andere Systeme, die weiterhin WS-Federation verwenden, während neue Anwendungen und APIs OpenID Connect und OAuth 2.0 weiterverwenden können.

Eine Umgebung, ein Identity Provider

Alle Bridge-Funktionen können in derselben FoxIDs-Umgebung kombiniert werden. Beispielsweise kann eine OpenID Connect-Anwendung die Anmeldung gleichzeitig über SAML 2.0- und OpenID Connect-Authentifizierungsmethoden unterstützen.

Es ist oft einfacher, Anwendungen und APIs einer FoxIDs-Umgebung als Identity Provider (IdP) vertrauen zu lassen, auch wenn Benutzer über unterschiedliche externe Protokolle authentifiziert werden. In diesem Modell:

  • Werden Anwendungen in FoxIDs mit dem Protokoll registriert, das sie bereits unterstützen.
  • Werden externe Identity Provider als Authentifizierungsmethoden konfiguriert.
  • Führt FoxIDs Protokollübersetzung und Claim Mapping zwischen den beiden Seiten aus.
  • Können OpenID Connect-Clients und OAuth 2.0-APIs ID Tokens und Access Tokens weiterverwenden, auch wenn die ursprüngliche Anmeldung aus SAML 2.0 oder WS-Federation kam.

Dieses Modell ist besonders nützlich, wenn eine Anwendungslandschaft schrittweise modernisiert wird. Bestehende SAML 2.0- und WS-Federation-Systeme können weiterlaufen, während neue Anwendungen OpenID Connect und OAuth 2.0 verwenden.

Token exchange

Wenn sich ein Benutzer über einen externen SAML 2.0 IdP bei einer SAML 2.0-Anwendung anmeldet, erhält die Anwendung ein SAML 2.0-Token für diesen Benutzer. In Zero Trust-Architekturen sollten APIs weiterhin im Kontext des Endbenutzers aufgerufen werden.

Verwenden Sie Token exchange, wenn ein SAML 2.0-Token gegen ein OAuth 2.0 Access Token ausgetauscht werden muss. Das resultierende Access Token kann verwendet werden, um OAuth 2.0-fähige APIs im Kontext des angemeldeten Benutzers aufzurufen.

Zuordnung von Ansprüchen

FoxIDs verwendet intern JWT-Claims und ordnet SAML 2.0-Claims den JWT-Claims zu. Das gleiche SAML-/JWT-Claim-Zuordnungsmodell wird auch für WS-Federation verwendet, da WS-Federation-Token SAML-Claims enthalten.

Standardmäßig werden Standardzuordnungen angewendet, zum Beispiel sub zu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier und email zu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Sie können die Zuordnungen von Ansprüchen in der Registerkarte Einstellungen > Anspruchszuordnungen der Umgebung einsehen und konfigurieren; dies wird unter Umgebungseinstellungen beschrieben. Wenn für einen Anspruch keine Zuordnung vorhanden ist, behält FoxIDs den ursprünglichen Anspruchsnamen bei. Dadurch bleiben die Ansprüche über die Brücke hinweg erhalten, während gleichzeitig kürzere Anspruchsnamen nach dem Muster JWT verwendet werden können, sofern Zuordnungen konfiguriert sind.

Benutzerdefinierte Zuordnungen

Benutzerdefinierte Zuordnungen gehören zur Umgebung und ordnen einen JWT-Claim-Typ einem SAML-Claim-Typ zu. Eine benutzerdefinierte Zuordnung hat Vorrang vor einer änderbaren Standardeinstellung für denselben eingehenden Claim-Typ, kann jedoch eine gesperrte Standardzuordnung nicht außer Kraft setzen.

Wenn in den Umgebungseinstellungen die Option Zuordnungen zwischen JWT und SAML-Claim-Typen automatisch erstellen aktiviert ist, kann FoxIDs bei der Verarbeitung benutzerdefinierte Zuordnungen für bisher nicht zugeordnete Claim-Typen hinzufügen. Sie können benutzerdefinierte Zuordnungen auch manuell hinzufügen, bearbeiten oder entfernen.

Standardzuordnungen

Standardmäßige SAML 2.0- und JWT-Claim-Zuordnungen sind in FoxIDs integriert und im Control Client schreibgeschützt. Gesperrte Standardzuordnungen werden stets erzwungen. Änderbare Standardzuordnungen werden nur verwendet, wenn für den eingehenden Claim-Typ keine benutzerdefinierte Zuordnung Vorrang hat.