Eine Anwendung und ihr identity provider müssen nicht dasselbe Föderationsprotokoll unterstützen. Eine moderne Anwendung kann OpenID Connect verwenden, während ein etablierter Unternehmens- oder Partner identity provider weiterhin SAML 2.0 nutzt. Eine Seite nur deshalb neu zu entwickeln, damit die Protokolle übereinstimmen, kann Kosten, Migrationsrisiken und unnötige Abhängigkeiten verursachen.
Eine SAML zu OpenID Connect bridge lässt beide Seiten das bereits unterstützte Protokoll beibehalten. FoxIDs validiert die SAML 2.0 Antwort des externen identity providers, wendet die erforderlichen claims und Sicherheitsregeln an und stellt die von der Anwendung erwartete OpenID Connect Antwort aus.
Suchen nach diesem Problem verwenden häufig kurze technische Begriffe wie SAML zu OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, Protokollübersetzung, SAML zu OIDC Übersetzung, token translation, identity broker oder identity federation broker. Die zentrale Architekturfrage bleibt dieselbe: Wie kann eine Anwendung einem modernen OpenID Connect Vertrag vertrauen, während ein bestehender identity provider, Partner oder eine ältere SAML Anwendung weiterhin das bereits unterstützte Protokoll nutzt?
Dabei wird nicht nur ein Tokenformat in ein anderes umgewandelt. Eine belastbare bridge muss die beabsichtigte Identität, authentication assurance und den Anwendungsvertrag über zwei Standards mit unterschiedlichen Nachrichtenformaten, Signaturmodellen, Sitzungsverhalten und claim Konventionen hinweg erhalten.
Wann protocol bridging das richtige Muster ist
Protocol bridging ist sinnvoll, wenn es eine kontrollierte Grenze zwischen Systemen schafft, die sich unterschiedlich schnell verändern müssen.
Typische Situationen:
- Eine neue Web-, Mobil- oder Single-Page-Anwendung unterstützt OpenID Connect, Kunden oder Partner authentifizieren sich jedoch über SAML 2.0 identity providers.
- Bestehende SAML 2.0 Anwendungen sollen einen modernen OpenID Connect identity provider verwenden.
- Eine Organisation ersetzt AD FS oder eine andere Föderationsplattform schrittweise, zum Beispiel in einer AD FS zu OpenID Connect Migration, statt alle Anwendungen gleichzeitig umzustellen.
- Mehrere Anwendungen sollen einer Identitätsschicht vertrauen, obwohl externe identity providers unterschiedliche Protokolle verwenden.
- Eine Migration benötigt parallele Test- und Produktionsumgebungen sowie einen klaren rollback Weg.
Wenn beide Seiten bereits dasselbe geeignete Protokoll unterstützen und sicher verbunden werden können, bringt eine bridge möglicherweise keinen Mehrwert. Verwenden Sie sie, wenn sie Kopplung reduziert oder eine schrittweise Änderung ermöglicht, nicht nur weil Protokollübersetzung möglich ist.
Entscheiden Sie frühzeitig, ob die bridge eine Migrationsphase oder eine langfristige Architekturkomponente ist. Eine vorübergehende bridge benötigt eindeutige Ausstiegskriterien für das Entfernen der alten trust Beziehung. Eine langfristige bridge benötigt klar benannte Betriebsverantwortung, Monitoring und Zertifikats-Lifecycle-Management auf beiden Seiten.
Zuerst den Vertrag zur Anwendung festlegen
Das anwendungsseitige Protokoll sollte normalerweise zur Architektur und langfristigen Ausrichtung der Anwendung passen. Neue Anwendungen verwenden häufig OpenID Connect für die Anmeldung und OAuth 2.0 für API-Zugriffe. Bestehende Unternehmensanwendungen müssen gegebenenfalls bei SAML 2.0 bleiben, solange sie unterstützt oder ersetzt werden.
In FoxIDs wird die Anwendung mit dem von ihr verwendeten Protokoll registriert. Der externe identity provider wird als authentication method mit seinem angebotenen Protokoll konfiguriert. FoxIDs liegt an der trust Grenze zwischen beiden:
SAML 2.0 identity provider → FoxIDs → OpenID Connect Anwendung
Auch die umgekehrte Richtung ist möglich:
OpenID Connect identity provider → FoxIDs → SAML 2.0 Anwendung
Durch diese Trennung können Anwendungsteams einen Anwendungsvertrag standardisieren, ohne dass alle externen identity providers gleichzeitig geändert werden müssen.
Identitätssemantik statt nur claim Namen bewahren
SAML assertions und OpenID Connect tokens stellen Identität unterschiedlich dar. Eine direkte Zuordnung von Namen reicht für ein Produktionsdesign selten aus.
Definieren Sie den Anwendungsvertrag ausdrücklich:
- Welcher Identifikator bleibt für dieselbe Person über Sitzungen und identity providers hinweg stabil?
- Welche claims werden für Anzeige, Autorisierung und Audit benötigt?
- Wie werden Gruppen und Rollen dargestellt, gefiltert und transformiert?
- Welchem issuer und welcher audience vertraut die Anwendung?
- Was geschieht, wenn ein externer provider einen erforderlichen claim nicht liefert?
- Können Identitäten mehrerer providers sicher korreliert werden oder müssen sie getrennt bleiben?
FoxIDs verwendet intern JWT claims und kann SAML claim Typen auf die kürzeren, in OpenID Connect üblichen claim Namen abbilden. Dieses claim mapping kann Werte transformieren, bevor sie die Anwendung erreichen. Halten Sie das Mapping bewusst klein: Stellen Sie die benötigten claims aus, statt jedes externe Attribut in jedes token zu kopieren.
Stabile Identifikatoren erfordern besondere Sorgfalt. E-Mail-Adressen und Benutzernamen können sich ändern und sind meist schlechte Primärschlüssel. Bevorzugen Sie einen unveränderlichen Quellidentifikator zusammen mit einem klar definierten issuer oder einen anderen Identifikator mit kontrolliertem Lebenszyklus.
Eine Identität durch die bridge verfolgen
Betrachten Sie einen Partnerbenutzer, der sich über einen SAML 2.0 identity provider anmeldet, während die Anwendung OpenID Connect verwendet:
- Die SAML assertion liefert ein unveränderliches
NameID, eine E-Mail-Adresse, Gruppenmitgliedschaften und einen authentication context. - FoxIDs validiert Signatur, issuer, audience und Gültigkeitsdauer. Anschließend wird der stabile Quellidentifikator auf
sub, ausgewählte Gruppen auf Anwendungsrollen und der akzeptierte authentication context aufacrabgebildet. - Die Anwendung erhält nur die vereinbarten OpenID Connect claims und validiert FoxIDs als issuer.
Die Anwendung benötigt keine partnerspezifische SAML Logik. Wird ein weiterer Partner identity provider hinzugefügt, werden dessen claims und assurance Signale an der FoxIDs Grenze normalisiert, ohne den Tokenvertrag der Anwendung zu ändern.
Authentication assurance bewusst behandeln
Eine erfolgreiche SAML Anmeldung teilt einer OpenID Connect Anwendung nicht automatisch mit, ob MFA verwendet oder welche assurance Anforderungen erfüllt wurden.
Definieren Sie, wie der SAML authentication context zum OpenID Connect authentication context und zu den von der Anwendung erwarteten acr Werten passt. Entscheiden Sie, ob FoxIDs die externe assurance akzeptieren kann, den externen identity provider zu einem stärkeren authentication step auffordern muss oder die Anmeldung ablehnen soll, wenn der benötigte context fehlt.
Dasselbe gilt in umgekehrter Richtung. Eine SAML 2.0 Anwendung kann einen bestimmten authentication context erwarten, obwohl sich der Benutzer über einen OpenID Connect identity provider anmeldet.
Leiten Sie starke authentication nicht allein aus einer bestehenden Sitzung beim externen identity provider ab. Prüfen Sie den zurückgegebenen authentication context anhand der konfigurierten assurance Regeln und testen Sie erfolgreiche sowie abgewiesene Abläufe.
Anmeldesitzungen von Logoutinformationen unterscheiden
OpenID Connect und SAML 2.0 verwenden unterschiedliche Sitzungs- und Logoutmechanismen. Der externe identity provider und die Anwendung verwalten jeweils ihre eigene Anmeldesitzung. FoxIDs verwaltet dazwischen keine dritte Anmeldesitzung für den Benutzer, sondern speichert nur die Sitzungsinformationen, die zur Koordination des Logout erforderlich sind.
Bei Anmeldung, reauthentication und step-up sendet FoxIDs eine authentication request an den externen identity provider. FoxIDs verwendet die Logoutinformationen nicht als Anmeldesitzung. Der externe identity provider entscheidet anhand seiner eigenen Sitzung und der Anforderungen der request, ob der Benutzer ohne Interaktion fortfahren kann oder sich erneut authentifizieren muss.
FoxIDs kann die gespeicherten Logoutinformationen verwenden, um Logout über die relevanten Beziehungen hinweg zu koordinieren. End-to-End single logout kann funktionieren, wenn alle Beteiligten kompatible Logoutabläufe unterstützen und der Browser jeden endpoint erreicht. Das darf jedoch nicht vorausgesetzt werden. Testen Sie front-channel redirects, abgelaufene externe Sitzungen, partiellen Logout, mehrere Anwendungen und provider-initiierten Logout, sofern erforderlich.
Stimmen Sie die Lebenszeiten von Anwendung und Tokens auf das erwartete Sitzungsverhalten des externen identity providers ab. Das Beenden der Anwendungssitzung beendet nicht zwangsläufig die externe Sitzung. Anforderungen an reauthentication und step-up müssen dagegen in einer neuen request übermittelt und anhand des zurückgegebenen authentication context geprüft werden.
Eine schrittweise SAML zu OpenID Connect Migration planen
Bei einer kontrollierten Migration bleiben bridge, Anwendungsvertrag und rollback Weg sichtbar.
- Bestehende Beziehungen erfassen. Dokumentieren Sie Anwendungen, identity providers, Metadaten, Zertifikate, endpoints, claims, Identifikatoren, MFA-Anforderungen, Sitzungsverhalten und Verantwortliche.
- Zielvertrag definieren. Legen Sie fest, welche Anwendungen OpenID Connect verwenden, welche SAML 2.0 Beziehungen bestehen bleiben und welche claims und assurance Signale die bridge passieren müssen.
- Beide trust Beziehungen konfigurieren. Fügen Sie den externen provider als FoxIDs authentication method und die Anwendung als FoxIDs application registration hinzu.
- Fehlerpfade ebenso wie Anmeldung testen. Berücksichtigen Sie ungültige Signaturen, falschen issuer oder audience, fehlende claims, abgelaufene assertions, Replay-Schutz, Zeitabweichungen, Logout und Zertifikatswechsel.
- In einer separaten Umgebung ausführen. Validieren Sie die Integration ohne Produktionsverkehr zu ändern und führen Sie die geprüfte Konfiguration kontrolliert durch die Umgebungen.
- Zuerst eine begrenzte Zielgruppe umstellen. Nutzen Sie eine Pilotanwendung, einen Partner oder eine Benutzergruppe und behalten Sie den bisherigen Weg, bis der neue belegt ist.
- Beobachten und cut-over abschließen. Überwachen Sie authentication Fehler, claim Abweichungen und Supportfälle, bevor die alte trust Beziehung entfernt wird.
FoxIDs tenants können getrennte Umgebungen für Entwicklung, Test, Migration und Produktion enthalten. Das unterstützt parallele Validierung und einen schrittweisen cut-over, ersetzt aber keinen rollback Plan und keine Tests auf Anwendungsebene.
Produktionsnachweise vor dem cut-over verlangen
Die bridge wird Teil des authentication Pfads und muss als Sicherheitsgrenze betrieben werden. Vereinbaren Sie die erforderlichen Nachweise für jede Produktionsentscheidung, statt eine erfolgreiche Anmeldung als Abnahme zu behandeln.
| Entscheidungsbereich | Vor der Produktion erforderlicher Nachweis |
|---|---|
| Trust endpoints | Benannte Verantwortliche, geprüfte Metadaten und Einschränkungen für issuer, audience, recipient und redirect URIs |
| Credentials | Getrennte kontrollierte Schlüssel, akzeptierte Algorithmen, ein getesteter Zertifikatswechsel und eine verantwortliche Person für die Erneuerung |
| Identitätsvertrag | Ein stabiles subject, eine Liste zulässiger claims, dokumentierte Transformationen und definiertes Verhalten bei fehlenden Pflicht-claims |
| Authentication assurance | Akzeptierte externe contexts, Regeln für zusätzliche MFA und getestete Ablehnungspfade |
| Anmeldung und Logout | Getestete Weiterleitung von requests für Anmeldung, reauthentication und step-up sowie Logout, partieller Logout und die relevanten Token- und externen Sitzungslebenszeiten |
| Fehler und Betrieb | Tests für ungültige, abgelaufene und wiederholte Nachrichten sowie Auditprotokolle, Alarme, Supportverantwortung und eine rollback Entscheidung |
Kopieren Sie private Schlüssel nicht zwischen Systemen, nur um eine Migration zu vereinfachen. Geben Sie jeder trust Beziehung eigene kontrollierte credentials und planen Sie die Rotation vor Ablauf der Zertifikate.
So unterstützt FoxIDs die bridge
FoxIDs implementiert protocol bridging über sein normales Modell für applications und authentication methods. Es muss kein separater bridge service bereitgestellt werden. Eine OpenID Connect Anwendung kann SAML 2.0, OpenID Connect oder WS-Federation authentication methods verwenden; einer SAML 2.0 Anwendung stehen dieselben externen Quellen zur Verfügung.
Anwendungsteams erhalten damit einen FoxIDs identity provider Vertrag, während identity providers, Partner und ältere Systeme über ihre unterstützten Standards angebunden werden. FoxIDs bietet außerdem claim mapping, konfigurierbare authentication flows, MFA und getrennte Test- und Produktionsumgebungen.
Die Dokumentation zur protocol bridge beschreibt das genaue Konfigurationsmodell, authentication methods und application registrations. Umfasst die Arbeit Anwendungs-Onboarding, claim Design, Tests oder eine schrittweise Migration, beschreibt FoxIDs Identity Integration die verfügbare Implementierungsunterstützung durch das Team hinter der Plattform.
Fazit
Eine SAML zu OpenID Connect bridge ist besonders wertvoll, wenn Anwendungen und identity providers sich unabhängig weiterentwickeln können, ohne den Identitätsvertrag zwischen ihnen zu schwächen.
Behandeln Sie die bridge als bewusste trust Grenze, nicht als unsichtbaren Tokenübersetzer. Wenn Anwendungsvertrag, assurance Regeln, Anmelde- und Logoutverhalten, Produktionsnachweise, Verantwortung und rollback ausdrücklich festgelegt sind, stellt FoxIDs das standardbasierte Implementierungsmodell für eine kontrollierte Einführung bereit.