Een applicatie en de bijbehorende identity provider hoeven niet hetzelfde federatieprotocol te ondersteunen. Een moderne applicatie kan OpenID Connect gebruiken terwijl een gevestigde identity provider van een organisatie of partner nog SAML 2.0 gebruikt. Een van beide zijden alleen herschrijven om de protocollen gelijk te maken kan extra kosten, migratierisico en onnodige afhankelijkheden veroorzaken.

Met een SAML naar OpenID Connect bridge behoudt iedere zijde het protocol dat al wordt ondersteund. FoxIDs valideert het SAML 2.0 antwoord van de externe identity provider, past de vereiste claims en beveiligingsregels toe en geeft het OpenID Connect antwoord uit dat de applicatie verwacht.

Zoekopdrachten naar dit probleem gebruiken vaak korte technische termen zoals SAML naar OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, protocolvertaling, SAML naar OIDC vertaling, token translation, identity broker of identity federation broker. De belangrijke architectuurvraag blijft dezelfde: hoe kan een applicatie vertrouwen op een modern OpenID Connect contract terwijl een bestaande identity provider, partner of oudere SAML applicatie het protocol blijft gebruiken dat al wordt ondersteund?

Dit is meer dan het omzetten van het ene tokenformaat in het andere. Een bruikbare bridge moet de bedoelde identiteit, authentication assurance en het applicatiecontract behouden tussen twee standaarden met verschillende berichtformaten, ondertekeningsmodellen, sessiegedrag en claim conventies.

Wanneer protocol bridging het juiste patroon is

Protocol bridging is waardevol wanneer het een gecontroleerde grens vormt tussen systemen die in een verschillend tempo moeten veranderen.

Veelvoorkomende situaties zijn:

  • Een nieuwe web-, mobiele of single-page applicatie ondersteunt OpenID Connect, maar klanten of partners authenticeren via SAML 2.0 identity providers.
  • Bestaande SAML 2.0 applicaties moeten een moderne OpenID Connect identity provider gebruiken.
  • Een organisatie vervangt AD FS of een ander federatieplatform stapsgewijs, bijvoorbeeld in een AD FS naar OpenID Connect migratie, in plaats van alle applicaties tegelijk te wijzigen.
  • Meerdere applicaties moeten één identiteitslaag vertrouwen, terwijl externe identity providers verschillende protocollen gebruiken.
  • Een migratie vereist parallelle test- en productieomgevingen met een duidelijke rollback route.

Als beide zijden al hetzelfde geschikte protocol ondersteunen en veilig kunnen worden verbonden, voegt een bridge mogelijk niets toe. Gebruik deze wanneer zij koppeling vermindert of een gefaseerde wijziging mogelijk maakt, niet alleen omdat protocolvertaling mogelijk is.

Bepaal vroeg of de bridge een migratiefase of een langdurig architectuuronderdeel is. Een tijdelijke bridge heeft duidelijke exitcriteria nodig voor het verwijderen van de oude trust relatie. Een langdurige bridge vereist benoemd operationeel eigenaarschap, monitoring en beheer van de levenscyclus van certificaten aan beide zijden.

Kies eerst het contract met de applicatie

Het protocol aan de applicatiezijde hoort meestal aan te sluiten op de architectuur en langetermijnrichting van de applicatie. Nieuwe applicaties gebruiken vaak OpenID Connect voor aanmelden en OAuth 2.0 voor API-toegang. Bestaande bedrijfsapplicaties moeten mogelijk SAML 2.0 blijven gebruiken zolang zij worden ondersteund of vervangen.

In FoxIDs wordt de applicatie geregistreerd met het protocol dat zij gebruikt. De externe identity provider wordt als authentication method geconfigureerd met het aangeboden protocol. FoxIDs bevindt zich op de trust grens ertussen:

SAML 2.0 identity provider → FoxIDs → OpenID Connect applicatie

De omgekeerde richting is ook mogelijk:

OpenID Connect identity provider → FoxIDs → SAML 2.0 applicatie

Door deze scheiding kunnen applicatieteams één applicatiecontract standaardiseren zonder te eisen dat alle externe identity providers tegelijk veranderen.

Twee routes voor protocol bridging via FoxIDs: SAML 2.0 naar OpenID Connect en OpenID Connect naar SAML 2.0.
FoxIDs laat de applicatie en identiteitsprovider de protocollen gebruiken die ze ondersteunen, met FoxIDs als gemeenschappelijke vertrouwensgrens.

Behoud identiteitsbetekenis, niet alleen claim namen

SAML assertions en OpenID Connect tokens geven identiteit anders weer. Een rechtstreekse naam-op-naam mapping is zelden genoeg voor productie.

Definieer het applicatiecontract expliciet:

  • Welke identifier blijft voor dezelfde persoon stabiel over sessies en identity providers?
  • Welke claims zijn nodig voor weergave, autorisatie en audit?
  • Hoe worden groepen en rollen weergegeven, gefilterd en getransformeerd?
  • Welke issuer en audience vertrouwt de applicatie?
  • Wat gebeurt er wanneer een externe provider een verplichte claim niet levert?
  • Kunnen identiteiten van meerdere providers veilig worden gecorreleerd of moeten zij gescheiden blijven?

FoxIDs gebruikt intern JWT claims en kan SAML claim typen mappen naar de kortere claim namen die vaak in OpenID Connect worden gebruikt. Deze claim mapping kan ook waarden transformeren voordat zij de applicatie bereiken. Houd de mapping bewust klein: geef de claims uit die de applicatie nodig heeft in plaats van ieder extern attribuut naar ieder token te kopiëren.

Stabiele identifiers vragen extra aandacht. E-mailadressen en gebruikersnamen kunnen veranderen en zijn meestal slechte primaire sleutels. Gebruik liever een onveranderlijke bronidentifier samen met een duidelijk gedefinieerde issuer of een andere identifier met een beheerde levenscyclus.

SAML 2.0 identificatoren, claims en authenticatiecontext via FoxIDs toegewezen aan OpenID Connect tokens.
De bridge wijst stabiele identificatoren, vereiste claims en assurance-signalen toe in plaats van elk attribuut van de externe identiteitsprovider te kopiëren.

Volg één identiteit door de bridge

Neem een partnergebruiker die zich aanmeldt via een SAML 2.0 identity provider terwijl de applicatie OpenID Connect gebruikt:

  • De SAML assertion levert een onveranderlijk NameID, een e-mailadres, groepslidmaatschap en een authentication context.
  • FoxIDs valideert de handtekening, issuer, audience en geldigheidsduur en mapt vervolgens de stabiele bronidentifier naar sub, geselecteerde groepen naar applicatierollen en de geaccepteerde authentication context naar acr.
  • De applicatie ontvangt alleen de afgesproken OpenID Connect claims en valideert FoxIDs als issuer.

De applicatie heeft geen partnerspecifieke SAML logica nodig. Wanneer een extra partner identity provider wordt toegevoegd, worden de claims en assurance-signalen bij de FoxIDs grens genormaliseerd zonder het tokencontract van de applicatie te wijzigen.

Behandel authentication assurance bewust

Een geslaagde SAML aanmelding vertelt een OpenID Connect applicatie niet automatisch of MFA is gebruikt of aan welke assurance eisen is voldaan.

Definieer hoe de SAML authentication context zich verhoudt tot de OpenID Connect authentication context en de acr waarden die de applicatie verwacht. Bepaal of FoxIDs externe assurance kan accepteren, de externe identity provider om een sterkere authentication step moet vragen of de aanmelding moet weigeren wanneer de vereiste context ontbreekt.

Hetzelfde geldt in de andere richting. Een SAML 2.0 applicatie kan een bepaalde authentication context verwachten, ook wanneer de gebruiker via een OpenID Connect identity provider aanmeldt.

Leid sterke authentication niet alleen af uit het bestaan van een sessie bij de externe identity provider. Beoordeel de teruggegeven authentication context aan de hand van de geconfigureerde assurance regels en test zowel geaccepteerde als geweigerde flows.

Onderscheid aanmeldsessies van uitloginformatie

OpenID Connect en SAML 2.0 gebruiken verschillende sessie- en uitlogmechanismen. De externe identity provider en de applicatie beheren ieder hun eigen aanmeldsessie. FoxIDs beheert daartussen geen derde aanmeldsessie voor de gebruiker, maar bewaart alleen de sessiegegevens die nodig zijn om uitloggen te coördineren.

Bij aanmelden, reauthentication en step-up stuurt FoxIDs een authentication request naar de externe identity provider. FoxIDs hergebruikt de uitloggegevens niet als aanmeldsessie. De externe identity provider bepaalt op basis van de eigen sessie en de eisen in de request of de gebruiker zonder interactie kan doorgaan of zich opnieuw moet authenticeren.

FoxIDs kan de bewaarde uitloggegevens gebruiken om uitloggen over de relevante relaties te coördineren. End-to-end single logout kan werken wanneer alle deelnemers compatibele logoutflows ondersteunen en de browser ieder endpoint kan bereiken, maar neem dit niet aan. Test front-channel redirects, verlopen externe sessies, gedeeltelijk uitloggen, meerdere applicaties en provider-geïnitieerd uitloggen waar dat nodig is.

Stem de levensduur van de applicatie en tokens af op het verwachte sessiegedrag van de externe identity provider. Het beëindigen van de applicatiesessie beëindigt niet vanzelf de externe sessie. Eisen voor reauthentication en step-up moeten in een nieuwe request worden meegestuurd en via de teruggegeven authentication context worden geverifieerd.

Plan een gefaseerde SAML naar OpenID Connect migratie

Een gecontroleerde migratie houdt de bridge, het applicatiecontract en de rollback route zichtbaar.

  1. Inventariseer bestaande relaties. Leg applicaties, identity providers, metadata, certificaten, endpoints, claims, identifiers, MFA-eisen, sessiegedrag en eigenaren vast.
  2. Definieer het doelcontract. Bepaal welke applicaties OpenID Connect gaan gebruiken, welke SAML 2.0 relaties blijven bestaan en welke claims en assurance signalen de bridge passeren.
  3. Configureer beide trust relaties. Voeg de externe provider toe als FoxIDs authentication method en de applicatie als FoxIDs application registration.
  4. Test foutpaden én aanmelden. Neem ongeldige handtekeningen, verkeerde issuer of audience, ontbrekende claims, verlopen assertions, replaybeveiliging, tijdsverschillen, uitloggen en certificaatrotatie mee.
  5. Werk in een aparte omgeving. Valideer de integratie zonder productieverkeer te wijzigen en voer de beoordeelde configuratie daarna gecontroleerd door de omgevingen.
  6. Verplaats eerst een beperkte doelgroep. Gebruik een pilotapplicatie, partner of gebruikersgroep en houd de vorige route beschikbaar tot de nieuwe is bewezen.
  7. Observeer en voltooi de cut-over. Bewaak authentication fouten, verschillen in claims en supportvragen voordat de oude trust relatie wordt verwijderd.

FoxIDs tenants kunnen aparte omgevingen bevatten voor ontwikkeling, test, migratie en productie. Dit ondersteunt parallelle validatie en gefaseerde cut-over, maar vervangt geen rollback plan of tests op applicatieniveau.

Migratie in zeven fasen van inventarisatie en doelcontract via trust configuratie, testen, gecontroleerde omgevingen en een pilot naar productieomschakeling, met rollback.
Een gefaseerde migratie valideert vertrouwensrelaties en applicatiegedrag vóór de productieomschakeling en houdt rollback beschikbaar totdat het nieuwe pad zich heeft bewezen.

Vereis productiebewijs vóór de cut-over

De bridge wordt onderdeel van het authentication pad en moet als beveiligingsgrens worden beheerd. Spreek voor iedere productiebeslissing het vereiste bewijs af in plaats van een geslaagde aanmelding als acceptatie te beschouwen.

Beslissingsgebied Vereist bewijs vóór productie
Trust endpoints Benoemde eigenaren, beoordeelde metadata en beperkingen voor issuer, audience, recipient en redirect URI's
Credentials Afzonderlijke beheerde sleutels, geaccepteerde algoritmen, een geteste certificaatrotatie en een eigenaar voor vernieuwing
Identiteitscontract Een stabiel subject, een lijst met toegestane claims, gedocumenteerde transformaties en gedefinieerd gedrag wanneer verplichte claims ontbreken
Authentication assurance Geaccepteerde externe contexts, regels voor extra MFA en geteste weigeringspaden
Aanmelden en uitloggen Geteste doorsturing van requests voor aanmelden, reauthentication en step-up, plus uitloggen, gedeeltelijk uitloggen en de relevante token- en externe sessieduur
Fouten en beheer Tests voor ongeldige, verlopen en opnieuw afgespeelde berichten, plus auditlogs, waarschuwingen, supportverantwoordelijkheid en een rollback beslissing

Kopieer geen private sleutels tussen systemen alleen om een migratie eenvoudiger te maken. Geef iedere trust relatie eigen beheerde credentials en plan rotatie voordat certificaten verlopen.

Hoe FoxIDs de bridge ondersteunt

FoxIDs implementeert protocol bridging via het normale model voor applications en authentication methods. Er hoeft geen aparte bridge service te worden geïnstalleerd. Een OpenID Connect applicatie kan SAML 2.0, OpenID Connect of WS-Federation authentication methods gebruiken, en een SAML 2.0 applicatie kan dezelfde externe bronnen gebruiken.

Applicatieteams krijgen zo één FoxIDs identity provider contract, terwijl identity providers, partners en oudere systemen via hun ondersteunde standaarden kunnen worden verbonden. FoxIDs biedt ook claim mapping, configureerbare authentication flows, MFA en aparte test- en productieomgevingen.

Gebruik de documentatie over de protocol bridge voor het precieze configuratiemodel, authentication methods en application registrations. Als het werk ook applicatie-onboarding, claim ontwerp, testen of gefaseerde migratie omvat, beschrijft FoxIDs Identity Integration de implementatiehulp van het team achter het platform.

Conclusie

Een SAML naar OpenID Connect bridge is het nuttigst wanneer applicaties en identity providers onafhankelijk kunnen evolueren zonder het identiteitscontract ertussen te verzwakken.

Behandel de bridge als een bewuste trust grens, niet als een onzichtbare tokenvertaler. Wanneer het applicatiecontract, de assurance regels, het aanmeld- en uitloggedrag, het productiebewijs, het eigenaarschap en rollback expliciet zijn, levert FoxIDs het op standaarden gebaseerde implementatiemodel om de wijziging gecontroleerd in te voeren.