SAML 2.0 / OpenID Connect Brücke
Standardmäßig ist FoxIDs eine Brücke zwischen SAML 2.0 und OpenID Connect / OAuth 2.0 ohne zusätzliche Konfiguration.
Föderiertes Identitätsmanagement (FIM) fokussiert auf die Verknüpfung von Identitäten über Domänen hinweg, während Single Sign-On (SSO) den Zugriff über Anwendungen hinweg vereinfacht. FoxIDs unterstützt sowohl FIM als auch SSO, und die Brücke ermöglicht dies über SAML 2.0 und OpenID Connect.
OpenID Connect (OIDC) und SAML 2.0 sind beide weit verbreitete Protokolle für Identitätsföderation, Single Sign on (SSO) und Benutzerauthentifizierung. Sie unterscheiden sich jedoch grundlegend in Struktur und Design. Manchmal müssen diese Protokolle verbunden oder integriert werden, zum Beispiel wenn eine Anwendung die OpenID Connect unterstützt, mit einem Identity Provider (IdP) arbeiten soll, der nur SAML 2.0 unterstützt.
Wesentliche Unterschiede der beiden Protokolltypen:
- OIDC: Baut auf OAuth 2.0 auf, ist ein modernes Protokoll für Web und Mobile Apps mit RESTful APIs. Nutzt JSON Web Tokens (JWT) für Identitätstokens und Access Tokens.
- SAML 2.0: XML basiert und auf browserbasierte SSO Szenarien fokussiert, häufig in Enterprise Umgebungen eingesetzt. Nutzt XML basierte Assertions / Tokens.
Um ein OpenID Connect System mit einem SAML 2.0 System zu verbinden, benötigen Sie eine Protokollübersetzung oder Brückenebene. Dies kann mit einer Zwischenkomponente erreicht werden, die sowohl als OpenID Connect Provider (OP) als auch als SAML Service Provider (SP) fungiert oder umgekehrt.
Wenn Sie eine SAML 2.0 Authentifizierungsmethode zu einem externen Identity Provider (IdP) konfigurieren und Ihre App als OpenID Connect Anwendung verbinden, wobei Sie die SAML 2.0 Authentifizierungsmethode auswählen, wird eine Login Anfrage Ihrer App als externe SAML 2.0 Login Anfrage weitergeleitet. Die SAML 2.0 Login Antwort wird anschließend zu einer OpenID Connect Antwort für Ihre App gemappt. SAML 2.0 Claims werden automatisch in JWT (OAuth 2.0) Claims konvertiert.
Das Gegenteil ist ebenso möglich, indem die Login Anfrage von einer SAML 2.0 application registration ausgeht und zu einem externen OpenID Provider (OP) geleitet wird, der als OpenID Connect Authentifizierungsmethode konfiguriert ist. Anschließend wird die Antwort in eine SAML 2.0 Antwort umgewandelt.
FoxIDs unterstützt das Bridging für Login, Logout und Single Logout zwischen SAML 2.0 und OpenID Connect.
Eine Umgebung - ein Identity Provider
Alle Bridge Funktionen können in derselben Umgebung kombiniert werden. Dadurch kann eine OpenID Connect App gleichzeitig Login über eine SAML 2.0 oder OpenID Connect Authentifizierungsmethode unterstützen. Die OpenID Connect App kann die Authentifizierungsmethode entweder programmgesteuert auswählen oder den Benutzer auf einer home realm discovery (HRD) Seite wählen lassen.
Es wird empfohlen, eine Anwendungsinfrastruktur mit OpenID Connect aktivierten Clients und OAuth 2.0 aktivierten APIs zu verwenden. Alle Anwendungen (Clients und APIs) vertrauen demselben Identity Provider (IdP) - ein IdP entspricht einer Umgebung in FoxIDs. Durch die Bridge Funktionalität in FoxIDs werden SAML 2.0 Tokens auf ID Tokens und Access Tokens gemappt, die zum Authentifizieren von OpenID Connect Apps und zum Aufrufen vorhandener APIs verwendet werden können.
Token exchange
Wenn einem Benutzer nach erfolgreichem Login mit einem externen SAML 2.0 Identity Provider (IdP) Zugriff auf eine SAML 2.0 App gewährt wird, erfolgt der Zugriff im Kontext des Benutzers selbst. Mit Zero Trust (niemals vertrauen, immer verifizieren) müssen Sie Ihre APIs im Kontext des Benutzers aufrufen. Dies ist mit Token exchange möglich, bei dem das SAML 2.0 Token gegen ein Access Token mit der Endbenutzeridentität eingetauscht wird. Anschließend kann Ihre OAuth 2.0 aktivierte API im Kontext des Benutzers aufgerufen werden.
Claim Mappings
FoxIDs verwendet intern JWT Claims und mappt SAML 2.0 Claims auf JWT Claims. Standardmäßig wird eine Reihe von Standard JWT zu SAML 2.0 Claims gemappt, z. B. sub zu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email zu http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress usw.
Sie können zusätzliche JWT zu SAML 2.0 Claim Mappings hinzufügen.
Wenn für einen bestimmten Claim kein Mapping existiert, bleibt der lange SAML 2.0 Claim Name aus dem SAML 2.0 Token erhalten, statt eines kürzeren entsprechenden JWT Claim Namens. Das Gleiche gilt in umgekehrter Richtung.