En applikasjon og dens identity provider trenger ikke å støtte den samme føderasjonsprotokollen. En moderne applikasjon kan bruke OpenID Connect, mens en etablert identity provider hos en virksomhet eller partner fortsatt bruker SAML 2.0. Å skrive om én av sidene bare for å få protokollene til å samsvare kan gi ekstra kostnader, migreringsrisiko og unødvendige avhengigheter.

En SAML til OpenID Connect bridge lar hver side beholde protokollen den allerede støtter. FoxIDs validerer SAML 2.0 svaret fra den eksterne identity provideren, bruker nødvendige claims og sikkerhetsregler og utsteder OpenID Connect svaret som applikasjonen forventer.

Søk etter dette problemet bruker ofte korte tekniske uttrykk som SAML til OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, protokolloversettelse, SAML til OIDC oversettelse, token translation, identity broker eller identity federation broker. Det viktige arkitekturspørsmålet er det samme: hvordan kan en applikasjon stole på en moderne OpenID Connect kontrakt mens en eksisterende identity provider, partner eller eldre SAML applikasjon fortsetter med protokollen den allerede støtter?

Dette er mer enn å endre ett tokenformat til et annet. En nyttig bridge må bevare tilsiktet identitet, authentication assurance og applikasjonskontrakt på tvers av to standarder med ulike meldingsformater, signeringsmodeller, sesjonsoppførsel og claim konvensjoner.

Når protocol bridging er riktig mønster

Protocol bridging er verdifullt når det skaper en kontrollert grense mellom systemer som må endres i ulikt tempo.

Vanlige situasjoner er:

  • En ny web-, mobil- eller single-page applikasjon støtter OpenID Connect, men kunder eller partnere autentiserer seg gjennom SAML 2.0 identity providers.
  • Eksisterende SAML 2.0 applikasjoner må bruke en moderne OpenID Connect identity provider.
  • En organisasjon erstatter AD FS eller en annen føderasjonsplattform gradvis, for eksempel i en AD FS til OpenID Connect migrering, i stedet for å endre alle applikasjoner samtidig.
  • Flere applikasjoner skal stole på ett identitetslag, selv om eksterne identity providers bruker forskjellige protokoller.
  • En migrering krever parallelle test- og produksjonsmiljøer med en tydelig rollback vei.

Hvis begge sider allerede støtter den samme egnede protokollen og kan kobles sikkert, tilfører en bridge kanskje ingen verdi. Bruk den når den reduserer kobling eller muliggjør en trinnvis endring, ikke bare fordi protokolloversettelse er mulig.

Avgjør tidlig om bridgen er et migreringstrinn eller en langsiktig arkitekturkomponent. En midlertidig bridge trenger tydelige kriterier for når den gamle trust relasjonen skal fjernes. En langsiktig bridge krever navngitt driftsansvar, overvåking og håndtering av sertifikatenes livssyklus på begge sider.

Velg først kontrakten mot applikasjonen

Protokollen mot applikasjonen bør normalt følge applikasjonens arkitektur og langsiktige retning. Nye applikasjoner bruker ofte OpenID Connect for innlogging og OAuth 2.0 for API-tilgang. Eksisterende bedriftsapplikasjoner kan ha behov for å fortsette med SAML 2.0 mens de støttes eller erstattes.

I FoxIDs registreres applikasjonen med protokollen den bruker. Den eksterne identity provideren konfigureres som en authentication method med protokollen den tilbyr. FoxIDs ligger ved trust grensen mellom dem:

SAML 2.0 identity provider → FoxIDs → OpenID Connect applikasjon

Motsatt retning er også mulig:

OpenID Connect identity provider → FoxIDs → SAML 2.0 applikasjon

Denne separasjonen gjør at applikasjonsteam kan standardisere én applikasjonskontrakt uten å kreve at alle eksterne identity providers endres samtidig.

To protocol bridging-flyter gjennom FoxIDs: SAML 2.0 til OpenID Connect og OpenID Connect til SAML 2.0.
FoxIDs lar applikasjonen og identitetsleverandøren bruke protokollene de støtter, med FoxIDs som felles tillitsgrense.

Bevar betydningen av identiteten, ikke bare claim navn

SAML assertions og OpenID Connect tokens representerer identitet forskjellig. En direkte navn-til-navn mapping er sjelden tilstrekkelig i en produksjonsløsning.

Definer applikasjonskontrakten eksplisitt:

  • Hvilken identifikator er stabil for samme person på tvers av sesjoner og identity providers?
  • Hvilke claims kreves for visning, autorisasjon og audit?
  • Hvordan representeres, filtreres og transformeres grupper og roller?
  • Hvilken issuer og audience stoler applikasjonen på?
  • Hva skjer når en ekstern provider mangler et obligatorisk claim?
  • Kan identiteter fra flere providers korreleres sikkert, eller må de holdes adskilt?

FoxIDs bruker JWT claims internt og kan mappe SAML claim typer til de kortere claim navnene som ofte brukes i OpenID Connect. Denne claim mappingen kan også transformere verdier før de når applikasjonen. Hold mappingen bevisst begrenset: utsted de claims applikasjonen trenger, i stedet for å kopiere alle eksterne attributter til hvert token.

Stabile identifikatorer krever særlig omtanke. E-postadresser og brukernavn kan endres og er vanligvis dårlige primærnøkler. Foretrekk en uforanderlig kildeidentifikator sammen med en tydelig definert issuer eller en annen identifikator med en kontrollert livssyklus.

SAML 2.0 identifikatorer, claims og authentication context mappet gjennom FoxIDs til OpenID Connect tokens.
Bridgen mapper stabile identifikatorer, nødvendige claims og assurance-signaler i stedet for å kopiere alle attributter fra den eksterne identitetsleverandøren.

Følg én identitet gjennom bridgen

Tenk på en partnerbruker som logger inn gjennom en SAML 2.0 identity provider mens applikasjonen bruker OpenID Connect:

  • SAML assertionen leverer et uforanderlig NameID, en e-postadresse, gruppemedlemskap og en authentication context.
  • FoxIDs validerer signatur, issuer, audience og gyldighetstid og mapper deretter den stabile kildeidentifikatoren til sub, utvalgte grupper til applikasjonsroller og den aksepterte authentication context til acr.
  • Applikasjonen mottar bare de avtalte OpenID Connect claims og validerer FoxIDs som issuer.

Applikasjonen trenger ikke partnerspesifikk SAML logikk. Når enda en partner identity provider legges til, normaliseres dens claims og assurance-signaler ved FoxIDs grensen uten å endre applikasjonens tokenkontrakt.

Håndter authentication assurance bevisst

En fullført SAML innlogging forteller ikke automatisk en OpenID Connect applikasjon om MFA ble brukt eller hvilke assurance krav som ble oppfylt.

Definer hvordan SAML authentication context forholder seg til OpenID Connect authentication context og acr verdiene applikasjonen forventer. Avgjør om FoxIDs kan godta ekstern assurance, må be den eksterne identity provideren om et sterkere authentication step eller skal avvise innloggingen når nødvendig context mangler.

Det samme prinsippet gjelder i motsatt retning. En SAML 2.0 applikasjon kan forvente en bestemt authentication context selv om brukeren logger inn gjennom en OpenID Connect identity provider.

Ikke utled sterk authentication bare fra at det finnes en sesjon hos den eksterne identity provideren. Vurder den returnerte authentication context mot de konfigurerte assurance reglene, og test både godkjente og avviste flyter.

Skill innloggingssesjoner fra utloggingsinformasjon

OpenID Connect og SAML 2.0 har forskjellige mekanismer for sesjoner og utlogging. Den eksterne identity provideren og applikasjonen vedlikeholder hver sin innloggingssesjon. FoxIDs vedlikeholder ikke en tredje innloggingssesjon for brukeren mellom dem, men lagrer bare sesjonsinformasjonen som er nødvendig for å koordinere utlogging.

Ved innlogging, reauthentication og step-up sender FoxIDs en authentication request til den eksterne identity provideren. FoxIDs gjenbruker ikke utloggingsinformasjonen som en innloggingssesjon. Den eksterne identity provideren avgjør ut fra sin egen sesjon og kravene i requesten om brukeren kan fortsette uten interaksjon eller må autentisere seg på nytt.

FoxIDs kan bruke den lagrede utloggingsinformasjonen til å koordinere utlogging på tvers av de relevante relasjonene. End-to-end single logout kan fungere når alle deltakere støtter kompatible logoutflyter og nettleseren kan nå hvert endpoint, men det må ikke tas for gitt. Test front-channel redirects, utløpte eksterne sesjoner, delvis utlogging, flere applikasjoner og provider-initiert utlogging der det kreves.

Samordne levetiden for applikasjonen og tokens med forventet sesjonsoppførsel hos den eksterne identity provideren. Avslutning av applikasjonssesjonen avslutter ikke nødvendigvis den eksterne sesjonen. Krav om reauthentication og step-up må sendes i en ny request og verifiseres gjennom den returnerte authentication context.

Planlegg en trinnvis SAML til OpenID Connect migrering

En kontrollert migrering holder bridgen, applikasjonskontrakten og rollback veien synlige.

  1. Kartlegg nåværende relasjoner. Registrer applikasjoner, identity providers, metadata, sertifikater, endpoints, claims, identifikatorer, MFA-krav, sesjonsoppførsel og eiere.
  2. Definer målkontrakten. Bestem hvilke applikasjoner som skal bruke OpenID Connect, hvilke SAML 2.0 relasjoner som blir værende, og hvilke claims og assurance signaler som skal krysse bridgen.
  3. Konfigurer begge trust relasjonene. Legg til den eksterne provideren som en FoxIDs authentication method og applikasjonen som en FoxIDs application registration.
  4. Test feilflyter i tillegg til innlogging. Inkluder ugyldige signaturer, feil issuer eller audience, manglende claims, utløpte assertions, replay-beskyttelse, tidsforskjeller, utlogging og sertifikatbytte.
  5. Kjør i et separat miljø. Valider integrasjonen uten å endre produksjonstrafikken, og flytt deretter den gjennomgåtte konfigurasjonen kontrollert gjennom miljøene.
  6. Flytt først en begrenset målgruppe. Bruk en pilotapplikasjon, partner eller brukergruppe, og behold den tidligere veien til den nye er bevist.
  7. Observer og fullfør cut-over. Overvåk authentication feil, forskjeller i claims og supportsaker før den gamle trust relasjonen fjernes.

FoxIDs tenants kan inneholde separate miljøer for utvikling, test, migrering og produksjon. Det støtter parallell validering og trinnvis cut-over, men erstatter ikke en rollback plan eller testing på applikasjonsnivå.

Migrering i sju trinn fra kartlegging og målkontrakt gjennom trust konfigurasjon, test, kontrollerte miljøer og pilot til produksjonsbytte, med rollback.
En trinnvis migrering validerer trust-relasjoner og applikasjonsatferd før produksjonsbyttet og beholder rollback til den nye flyten er utprøvd.

Krev produksjonsdokumentasjon før cut-over

Bridgen blir en del av authentication veien og må drives som en sikkerhetsgrense. Avtal hvilken dokumentasjon som kreves for hver produksjonsbeslutning, i stedet for å behandle en vellykket innlogging som godkjenning.

Beslutningsområde Nødvendig dokumentasjon før produksjon
Trust endpoints Navngitte eiere, gjennomgåtte metadata og begrensninger for issuer, audience, recipient og redirect URI-er
Credentials Separate kontrollerte nøkler, aksepterte algoritmer, en test av sertifikatbytte og en ansvarlig for fornyelse
Identitetskontrakt Et stabilt subject, en liste over tillatte claims, dokumenterte transformasjoner og definert oppførsel når obligatoriske claims mangler
Authentication assurance Aksepterte eksterne contexts, regler for ekstra MFA og testede avvisningsflyter
Innlogging og utlogging Testet videresending av requests for innlogging, reauthentication og step-up samt utlogging, delvis utlogging og relevante levetider for tokens og eksterne sesjoner
Feil og drift Test av ugyldige, utløpte og gjentatte meldinger samt auditlogger, varsler, supportansvar og en rollback beslutning

Unngå å kopiere private nøkler mellom systemer bare for å forenkle en migrering. Gi hver trust relasjon egne kontrollerte credentials, og planlegg rotasjon før sertifikatene utløper.

Slik støtter FoxIDs bridgen

FoxIDs implementerer protocol bridging gjennom den vanlige modellen for applications og authentication methods. Det finnes ingen separat bridge service å installere. En OpenID Connect applikasjon kan bruke SAML 2.0, OpenID Connect eller WS-Federation authentication methods, og en SAML 2.0 applikasjon kan bruke de samme eksterne kildene.

Dette gir applikasjonsteam én FoxIDs identity provider kontrakt, mens identity providers, partnere og eldre systemer kan kobles til gjennom standardene de støtter. FoxIDs tilbyr også claim mapping, konfigurerbare authentication flows, MFA og separate miljøer for test og produksjon.

Bruk dokumentasjonen om protocol bridge for den nøyaktige konfigurasjonsmodellen, authentication methods og application registrations. Hvis arbeidet omfatter onboarding av applikasjoner, claim design, testing eller trinnvis migrering, beskriver FoxIDs Identity Integration implementeringshjelpen fra teamet bak plattformen.

Konklusjon

En SAML til OpenID Connect bridge er mest nyttig når den lar applikasjoner og identity providers utvikle seg uavhengig uten å svekke identitetskontrakten mellom dem.

Behandle bridgen som en bevisst trust grense, ikke som en usynlig tokenoversetter. Når applikasjonskontrakten, assurance reglene, innloggings- og utloggingsoppførselen, produksjonsdokumentasjonen, ansvaret og rollback er tydelige, gir FoxIDs den standardbaserte implementeringsmodellen for å innføre endringen i kontrollerte trinn.