En applikation og dens identity provider behøver ikke at understøtte samme federationsprotokol. En moderne applikation kan bruge OpenID Connect, mens en etableret identity provider hos en virksomhed eller partner stadig bruger SAML 2.0. Hvis en af siderne omskrives alene for at få protokollerne til at passe sammen, kan det give ekstra omkostninger, migrationsrisiko og unødvendige afhængigheder.

En SAML til OpenID Connect bridge lader hver side beholde den protokol, den allerede understøtter. FoxIDs validerer SAML 2.0 svaret fra den eksterne identity provider, anvender de nødvendige claims og sikkerhedsregler og udsteder det OpenID Connect svar, som applikationen forventer.

Søgninger efter dette problem bruger ofte korte tekniske udtryk som SAML til OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, protokoloversættelse, SAML til OIDC oversættelse, token translation, identity broker eller identity federation broker. Det vigtige arkitekturspørgsmål er det samme: hvordan kan en applikation stole på en moderne OpenID Connect kontrakt, mens en eksisterende identity provider, partner eller ældre SAML applikation fortsætter med den protokol, den allerede understøtter?

Det er mere end at ændre ét tokenformat til et andet. En brugbar bridge skal bevare den tilsigtede identitet, authentication assurance og applikationskontrakt på tværs af to standarder med forskellige meddelelsesformater, signeringsmodeller, sessionsadfærd og claim konventioner.

Hvornår protocol bridging er det rigtige mønster

Protocol bridging er værdifuldt, når det skaber en kontrolleret grænse mellem systemer, der skal ændres i forskelligt tempo.

Typiske situationer er:

  • En ny web-, mobil- eller single-page applikation understøtter OpenID Connect, mens kunder eller partnere logger ind gennem SAML 2.0 identity providers.
  • Eksisterende SAML 2.0 applikationer skal bruge en moderne OpenID Connect identity provider.
  • En organisation erstatter AD FS eller en anden federationsplatform gradvist, for eksempel i en AD FS til OpenID Connect migration, i stedet for at ændre alle applikationer samtidig.
  • Flere applikationer skal have tillid til ét identitetslag, selvom de eksterne identity providers bruger forskellige protokoller.
  • En migration kræver parallelle test- og produktionsmiljøer med en tydelig rollback mulighed.

Hvis begge sider allerede understøtter den samme egnede protokol og kan forbindes sikkert, tilfører en bridge måske ingen værdi. Brug den, når den reducerer kobling eller muliggør en trinvis ændring, ikke blot fordi protokoloversættelse er mulig.

Beslut tidligt, om bridgen er et migrationstrin eller en langsigtet arkitekturkomponent. En midlertidig bridge skal have tydelige kriterier for, hvornår den gamle trust relation fjernes. En langsigtet bridge kræver placeret driftsansvar, monitorering og styring af certifikaternes livscyklus på begge sider.

Vælg først kontrakten mod applikationen

Protokollen mod applikationen bør normalt følge applikationens arkitektur og langsigtede retning. Nye applikationer bruger ofte OpenID Connect til login og OAuth 2.0 til API-adgang. Eksisterende virksomhedsapplikationer kan have behov for at blive på SAML 2.0, mens de fortsat understøttes eller afløses.

I FoxIDs registreres applikationen med den protokol, den forstår. Den eksterne identity provider konfigureres som en authentication method med den protokol, den tilbyder. FoxIDs ligger ved tillidsgrænsen mellem dem:

SAML 2.0 identity provider → FoxIDs → OpenID Connect applikation

Den modsatte retning er også mulig:

OpenID Connect identity provider → FoxIDs → SAML 2.0 applikation

Adskillelsen gør det muligt for applikationsteams at standardisere én applikationskontrakt uden at kræve, at alle eksterne identity providers ændres samtidig.

To protocol bridging-forløb gennem FoxIDs: SAML 2.0 til OpenID Connect og OpenID Connect til SAML 2.0.
FoxIDs lader applikationen og identity provideren bruge de protokoller, de understøtter, med FoxIDs som fælles trust-grænse.

Bevar identitetens betydning, ikke kun claim navne

SAML assertions og OpenID Connect tokens repræsenterer identitet forskelligt. En direkte mapping fra navn til navn er sjældent tilstrækkelig i et produktionsdesign.

Definér applikationskontrakten eksplicit:

  • Hvilken identifikator er stabil for samme person på tværs af sessioner og identity providers?
  • Hvilke claims kræves til visning, autorisation og audit?
  • Hvordan repræsenteres, filtreres og transformeres grupper og roller?
  • Hvilken issuer og audience har applikationen tillid til?
  • Hvad sker der, hvis en ekstern provider mangler et nødvendigt claim?
  • Kan identiteter fra flere providers korreleres sikkert, eller skal de forblive adskilte?

FoxIDs bruger JWT claims internt og kan mappe SAML claim typer til de kortere claim navne, der ofte bruges i OpenID Connect. Denne claim mapping kan også transformere værdier, før de når applikationen. Hold mappingen bevidst begrænset: udsted de claims, applikationen har brug for, i stedet for at kopiere alle eksterne attributter ind i hvert token.

Stabile identifikatorer kræver særlig omtanke. E-mailadresser og brugernavne kan ændres og er normalt dårlige primærnøgler. Foretræk en uforanderlig kildeidentifikator sammen med en klart defineret issuer eller en anden identifikator med en kontrolleret livscyklus.

SAML 2.0 identifikatorer, claims og authentication context mappet gennem FoxIDs til OpenID Connect tokens.
Bridgen mapper stabile identifikatorer, nødvendige claims og assurance-signaler i stedet for at kopiere alle attributter fra identity provideren.

Følg én identitet gennem bridgen

Tag som eksempel en partnerbruger, der logger ind gennem en SAML 2.0 identity provider, mens applikationen bruger OpenID Connect:

  • SAML assertionen leverer et uforanderligt NameID, en e-mailadresse, gruppemedlemskab og en authentication context.
  • FoxIDs validerer signatur, issuer, audience og levetid og mapper derefter den stabile kildeidentifikator til sub, udvalgte grupper til applikationsroller og den accepterede authentication context til acr.
  • Applikationen modtager kun de aftalte OpenID Connect claims og validerer FoxIDs som issuer.

Applikationen behøver ikke partnerspecifik SAML logik. Når endnu en partner identity provider tilføjes, normaliseres dens claims og assurance-signaler ved FoxIDs grænsen uden at ændre applikationens tokenkontrakt.

Håndtér authentication assurance bevidst

Et gennemført SAML login fortæller ikke automatisk en OpenID Connect applikation, om MFA blev brugt, eller hvilke assurance krav der blev opfyldt.

Definér, hvordan SAML authentication context forholder sig til den OpenID Connect authentication context og de acr værdier, som applikationen forventer. Beslut, om FoxIDs kan acceptere den eksterne assurance, skal anmode den eksterne identity provider om et stærkere authentication step eller skal afvise login, når den nødvendige context mangler.

Det samme princip gælder i den modsatte retning. En SAML 2.0 applikation kan forvente en bestemt authentication context, selvom brugeren logger ind gennem en OpenID Connect identity provider.

Udled ikke stærk authentication alene af, at der findes en session hos den eksterne identity provider. Vurdér den returnerede authentication context i forhold til de konfigurerede assurance regler, og test både godkendte og afviste forløb.

Skeln mellem login-sessioner og logout-information

OpenID Connect og SAML 2.0 har forskellige sessions- og logoutmekanismer. Den eksterne identity provider og applikationen vedligeholder hver deres login-session. FoxIDs vedligeholder ikke en tredje login-session for brugeren imellem dem, men gemmer kun den sessionsinformation, der er nødvendig for at koordinere logout.

Ved login, reauthentication og step-up sender FoxIDs en authentication request til den eksterne identity provider. FoxIDs genbruger ikke den logout-relaterede information som en login-session. Den eksterne identity provider afgør ud fra sin egen session og kravene i requestet, om brugeren kan fortsætte uden interaktion eller skal autentificeres igen.

FoxIDs kan bruge den gemte logout-information til at koordinere logout på tværs af de relevante relationer. End-to-end single logout kan fungere, når alle deltagere understøtter kompatible logoutflows, og browseren kan nå hvert endpoint, men det må ikke antages. Test front-channel redirects, udløbne eksterne sessioner, delvist logout, flere applikationer og provider-initieret logout, hvor det er nødvendigt.

Afstem applikations- og tokenlevetider med den forventede sessionsadfærd hos den eksterne identity provider. Afslutning af applikationssessionen afslutter ikke nødvendigvis den eksterne session, mens krav om reauthentication og step-up skal medsendes i et nyt request og verificeres gennem den returnerede authentication context.

Planlæg en trinvis SAML til OpenID Connect migration

En kontrolleret migration holder bridgen, applikationskontrakten og rollback vejen synlige.

  1. Kortlæg de nuværende relationer. Registrér applikationer, identity providers, metadata, certifikater, endpoints, claims, identifikatorer, MFA-krav, sessionsadfærd og ejere.
  2. Definér målkontrakten. Beslut hvilke applikationer der skal bruge OpenID Connect, hvilke SAML 2.0 relationer der bevares, og hvilke claims og assurance signaler der skal passere bridgen.
  3. Konfigurér begge trust relationer. Tilføj den eksterne provider som en FoxIDs authentication method og applikationen som en FoxIDs application registration.
  4. Test fejlforløb såvel som login. Medtag ugyldige signaturer, forkert issuer eller audience, manglende claims, udløbne assertions, replay-beskyttelse, tidsforskelle, logout og certifikatskift.
  5. Kør i et separat miljø. Validér integrationen uden at ændre produktionstrafik, og før derefter den gennemgåede konfiguration kontrolleret gennem miljøerne.
  6. Flyt først en begrænset målgruppe. Brug en pilotapplikation, partner eller brugergruppe, og behold den tidligere vej, indtil den nye er bevist.
  7. Observér og fuldfør cut-over. Overvåg authentication fejl, forskelle i claims og supportsager, før den gamle trust relation fjernes.

FoxIDs tenants kan indeholde separate miljøer til udvikling, test, migration og produktion. Det understøtter parallel validering og trinvis cut-over, men erstatter ikke en rollback plan eller test på applikationsniveau.

Migration i syv trin fra kortlægning og målkontrakt gennem trust-konfiguration, test, kontrollerede miljøer og pilot til produktionsskift med rollback.
En trinvis migration validerer trust-relationer og applikationsadfærd før produktionsskiftet og bevarer rollback, indtil det nye forløb er afprøvet.

Kræv dokumentation før cut-over

Bridgen bliver en del af authentication vejen og skal drives som en sikkerhedsgrænse. Aftal dokumentationen for hver produktionsbeslutning i stedet for at betragte et vellykket login som en godkendelse.

Beslutningsområde Nødvendig dokumentation før produktion
Trust endpoints Navngivne ejere, gennemgåede metadata og begrænsninger for issuer, audience, recipient og redirect URI'er
Credentials Separate kontrollerede nøgler, accepterede algoritmer, en test af certifikatskift og en ansvarlig for fornyelse
Identitetskontrakt Et stabilt subject, en liste over tilladte claims, dokumenterede transformationer og defineret adfærd, når nødvendige claims mangler
Authentication assurance Accepterede eksterne contexts, regler for ekstra MFA og testede afvisningsforløb
Login og logout Test af videresendelse af requests ved login, reauthentication og step-up samt logout, delvist logout og de relevante tokenlevetider og eksterne sessionslevetider
Fejl og drift Test af ugyldige, udløbne og genafspillede meddelelser samt auditlogs, alarmer, supportansvar og en rollback beslutning

Undgå at kopiere private nøgler mellem systemer alene for at forenkle en migration. Giv hver trust relation sine egne kontrollerede credentials, og planlæg rotation, før certifikater udløber.

Sådan understøtter FoxIDs bridgen

FoxIDs implementerer protocol bridging gennem den normale model for applications og authentication methods. Der skal ikke installeres en separat bridge service. En OpenID Connect applikation kan bruge SAML 2.0, OpenID Connect eller WS-Federation authentication methods, og en SAML 2.0 applikation kan bruge de samme eksterne kilder.

Det giver applikationsteams én FoxIDs identity provider kontrakt, mens identity providers, partnere og ældre systemer kan forbindes gennem de standarder, de understøtter. FoxIDs leverer også claim mapping, konfigurerbare authentication flows, MFA og separate miljøer til test og produktion.

Brug dokumentationen om protocol bridge til den præcise konfigurationsmodel, authentication methods og application registrations. Hvis arbejdet omfatter onboarding af applikationer, claim design, test eller trinvis migration, beskriver FoxIDs Identity Integration den implementeringshjælp, som teamet bag platformen tilbyder.

Konklusion

En SAML til OpenID Connect bridge er mest nyttig, når den lader applikationer og identity providers udvikle sig uafhængigt uden at svække identitetskontrakten mellem dem.

Behandl bridgen som en bevidst trust-grænse, ikke som en usynlig tokenoversætter. Når applikationskontrakten, assurance-reglerne, sessionsadfærden, dokumentationen før produktion, ansvaret og rollback er tydelige, leverer FoxIDs den standardbaserede implementeringsmodel til at indføre ændringen i kontrollerede trin.