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.

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.

Konfigurieren Sie den upstream Identity Provider als Authentifizierungsmethode:
- OpenID Connect-Authentifizierungsmethode
- SAML 2.0-Authentifizierungsmethode
- WS-Federation-Authentifizierungsmethode
Konfigurieren Sie die Anwendung als application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Wählen Sie in der application registration die Authentifizierungsmethode aus, die die Anmeldung verarbeiten soll.
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.
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

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.

Claim Mappings

FoxIDs verwendet intern JWT Claims und mappt SAML 2.0 Claims auf JWT Claims. Dasselbe SAML/JWT Claim Mapping-Modell wird auch für WS-Federation verwendet, weil WS-Federation-Tokens SAML Claims enthalten.

Standardmäßig werden Standardmappings 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 zusätzliche JWT zu SAML Claim Mappings in FoxIDs Control hinzufügen. Wenn kein Mapping für einen Claim existiert, behält FoxIDs den ursprünglichen Claim-Namen bei. Dadurch bleiben Claims über die Bridge hinweg erhalten, während kürzere JWT Claim-Namen verwendet werden können, wenn Mappings konfiguriert sind.