En applikation och dess identity provider behöver inte stödja samma federationsprotokoll. En modern applikation kan använda OpenID Connect medan en etablerad identity provider hos ett företag eller en partner fortfarande använder SAML 2.0. Att skriva om någon av sidorna enbart för att protokollen ska matcha kan öka kostnaden, migreringsrisken och antalet onödiga beroenden.
En SAML till OpenID Connect bridge låter båda sidor behålla det protokoll de redan stödjer. FoxIDs validerar SAML 2.0 svaret från den externa identity providern, tillämpar nödvändiga claims och säkerhetsregler och utfärdar det OpenID Connect svar som applikationen förväntar sig.
Sökningar efter det här problemet använder ofta korta tekniska uttryck som SAML till OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, protokollöversättning, SAML till OIDC översättning, token translation, identity broker eller identity federation broker. Den viktiga arkitekturfrågan är densamma: hur kan en applikation lita på ett modernt OpenID Connect kontrakt medan en befintlig identity provider, partner eller äldre SAML applikation fortsätter med det protokoll den redan stödjer?
Det handlar om mer än att byta ett tokenformat mot ett annat. En användbar bridge måste bevara avsedd identitet, authentication assurance och applikationskontrakt mellan två standarder med olika meddelandeformat, signeringsmodeller, sessionsbeteenden och claim konventioner.
När protocol bridging är rätt mönster
Protocol bridging är värdefullt när det skapar en kontrollerad gräns mellan system som behöver förändras i olika takt.
Vanliga situationer är:
- En ny webb-, mobil- eller single-page applikation stödjer OpenID Connect, men kunder eller partner autentiserar sig via SAML 2.0 identity providers.
- Befintliga SAML 2.0 applikationer behöver använda en modern OpenID Connect identity provider.
- En organisation ersätter AD FS eller en annan federationsplattform stegvis, till exempel i en AD FS till OpenID Connect migrering, i stället för att ändra alla applikationer samtidigt.
- Flera applikationer ska lita på ett identitetslager även om externa identity providers använder olika protokoll.
- En migrering kräver parallella test- och produktionsmiljöer med en tydlig rollback väg.
Om båda sidor redan stödjer samma lämpliga protokoll och kan anslutas säkert kanske en bridge inte ger något mervärde. Använd den när den minskar koppling eller möjliggör en stegvis förändring, inte bara för att protokollöversättning är möjlig.
Avgör tidigt om bridgen är ett migreringssteg eller en långsiktig arkitekturkomponent. En tillfällig bridge behöver tydliga kriterier för när den gamla trust relationen ska tas bort. En långsiktig bridge kräver utpekat driftansvar, övervakning och hantering av certifikatens livscykel på båda sidor.
Välj först kontraktet mot applikationen
Protokollet mot applikationen bör normalt följa applikationens arkitektur och långsiktiga inriktning. Nya applikationer använder ofta OpenID Connect för inloggning och OAuth 2.0 för API-åtkomst. Befintliga företagsapplikationer kan behöva ligga kvar på SAML 2.0 så länge de stöds eller ersätts.
I FoxIDs registreras applikationen med det protokoll den använder. Den externa identity providern konfigureras som en authentication method med det protokoll den erbjuder. FoxIDs ligger vid trust gränsen mellan dem:
SAML 2.0 identity provider → FoxIDs → OpenID Connect applikation
Den omvända riktningen är också möjlig:
OpenID Connect identity provider → FoxIDs → SAML 2.0 applikation
Separationen gör att applikationsteam kan standardisera ett applikationskontrakt utan att kräva att alla externa identity providers ändras samtidigt.
Bevara identitetens innebörd, inte bara claim namn
SAML assertions och OpenID Connect tokens representerar identitet på olika sätt. En direkt namn-till-namn mapping räcker sällan för en produktionslösning.
Definiera applikationskontraktet uttryckligen:
- Vilken identifierare är stabil för samma person mellan sessioner och identity providers?
- Vilka claims krävs för visning, auktorisering och audit?
- Hur representeras, filtreras och transformeras grupper och roller?
- Vilken issuer och audience litar applikationen på?
- Vad händer när en extern provider saknar ett obligatoriskt claim?
- Kan identiteter från flera providers korreleras säkert eller måste de förbli separata?
FoxIDs använder JWT claims internt och kan mappa SAML claim typer till de kortare claim namn som ofta används i OpenID Connect. Denna claim mapping kan också transformera värden innan de når applikationen. Håll mappingen avsiktligt begränsad: utfärda de claims som applikationen behöver i stället för att kopiera varje externt attribut till varje token.
Stabila identifierare kräver särskild omsorg. E-postadresser och användarnamn kan ändras och är vanligtvis dåliga primärnycklar. Föredra en oföränderlig källidentifierare tillsammans med en tydligt definierad issuer eller en annan identifierare vars livscykel är kontrollerad.
Följ en identitet genom bridgen
Ta en partneranvändare som loggar in via en SAML 2.0 identity provider medan applikationen använder OpenID Connect:
- SAML assertionen innehåller ett oföränderligt
NameID, en e-postadress, gruppmedlemskap och en authentication context. - FoxIDs validerar signatur, issuer, audience och giltighetstid och mappar sedan den stabila källidentifieraren till
sub, utvalda grupper till applikationsroller och den accepterade authentication context tillacr. - Applikationen tar endast emot överenskomna OpenID Connect claims och validerar FoxIDs som issuer.
Applikationen behöver ingen partnerspecifik SAML logik. När ytterligare en partner identity provider läggs till normaliseras dess claims och assurance-signaler vid FoxIDs gränsen utan att applikationens tokenkontrakt ändras.
Hantera authentication assurance medvetet
En genomförd SAML inloggning berättar inte automatiskt för en OpenID Connect applikation om MFA användes eller vilka assurance krav som uppfylldes.
Definiera hur SAML authentication context förhåller sig till den OpenID Connect authentication context och de acr värden som applikationen förväntar sig. Avgör om FoxIDs kan acceptera extern assurance, måste begära ett starkare authentication step från den externa identity providern eller ska avvisa inloggningen när nödvändig context saknas.
Samma princip gäller i omvänd riktning. En SAML 2.0 applikation kan förvänta sig en viss authentication context även när användaren loggar in via en OpenID Connect identity provider.
Härled inte stark authentication enbart från att en session finns hos den externa identity providern. Utvärdera den returnerade authentication context mot de konfigurerade assurance reglerna och testa både godkända och avvisade flöden.
Skilj inloggningssessioner från utloggningsinformation
OpenID Connect och SAML 2.0 har olika mekanismer för sessioner och utloggning. Den externa identity providern och applikationen hanterar var sin inloggningssession. FoxIDs hanterar inte en tredje inloggningssession för användaren mellan dem, utan lagrar endast den sessionsinformation som krävs för att samordna utloggning.
Vid inloggning, reauthentication och step-up skickar FoxIDs en authentication request till den externa identity providern. FoxIDs återanvänder inte utloggningsinformationen som en inloggningssession. Den externa identity providern avgör utifrån sin egen session och kraven i requesten om användaren kan fortsätta utan interaktion eller måste autentisera sig igen.
FoxIDs kan använda den lagrade utloggningsinformationen för att samordna utloggning mellan de relevanta relationerna. End-to-end single logout kan fungera när alla deltagare stödjer kompatibla logoutflöden och webbläsaren kan nå varje endpoint, men det får inte tas för givet. Testa front-channel redirects, utgångna externa sessioner, delvis utloggning, flera applikationer och provider-initierad utloggning där det krävs.
Samordna applikationens och tokens livslängder med det förväntade sessionsbeteendet hos den externa identity providern. Att avsluta applikationssessionen avslutar inte nödvändigtvis den externa sessionen. Krav på reauthentication och step-up måste skickas med i en ny request och verifieras genom den returnerade authentication context.
Planera en stegvis SAML till OpenID Connect migrering
En kontrollerad migrering håller bridgen, applikationskontraktet och rollback vägen synliga.
- Inventera nuvarande relationer. Dokumentera applikationer, identity providers, metadata, certifikat, endpoints, claims, identifierare, MFA-krav, sessionsbeteende och ägare.
- Definiera målkontraktet. Bestäm vilka applikationer som ska använda OpenID Connect, vilka SAML 2.0 relationer som finns kvar och vilka claims och assurance signaler som ska passera bridgen.
- Konfigurera båda trust relationerna. Lägg till den externa providern som en FoxIDs authentication method och applikationen som en FoxIDs application registration.
- Testa felflöden såväl som inloggning. Ta med ogiltiga signaturer, fel issuer eller audience, saknade claims, utgångna assertions, replay-skydd, tidsskillnader, utloggning och certifikatbyte.
- Kör i en separat miljö. Validera integrationen utan att ändra produktionstrafiken och flytta sedan den granskade konfigurationen kontrollerat genom miljöerna.
- Flytta först en begränsad målgrupp. Använd en pilotapplikation, partner eller användargrupp och behåll den tidigare vägen tills den nya har bevisats.
- Observera och slutför cut-over. Övervaka authentication fel, skillnader i claims och supportärenden innan den gamla trust relationen tas bort.
FoxIDs tenants kan innehålla separata miljöer för utveckling, test, migrering och produktion. Det stödjer parallell validering och stegvis cut-over men ersätter inte en rollback plan eller testning på applikationsnivå.
Kräv produktionsbevis före cut-over
Bridgen blir en del av authentication vägen och måste drivas som en säkerhetsgräns. Kom överens om vilka bevis som krävs för varje produktionsbeslut i stället för att behandla en lyckad inloggning som ett godkännande.
| Beslutsområde | Bevis som krävs före produktion |
|---|---|
| Trust endpoints | Namngivna ägare, granskad metadata och begränsningar för issuer, audience, recipient och redirect URI:er |
| Credentials | Separata kontrollerade nycklar, accepterade algoritmer, testat certifikatbyte och en ansvarig för förnyelse |
| Identitetskontrakt | Ett stabilt subject, en lista över tillåtna claims, dokumenterade transformationer och definierat beteende när obligatoriska claims saknas |
| Authentication assurance | Accepterade externa contexts, regler för ytterligare MFA och testade avvisningsflöden |
| Inloggning och utloggning | Testad vidarebefordran av requests för inloggning, reauthentication och step-up samt utloggning, delvis utloggning och relevanta livslängder för tokens och externa sessioner |
| Fel och drift | Test av ogiltiga, utgångna och återuppspelade meddelanden samt auditloggar, larm, supportansvar och ett rollback beslut |
Undvik att kopiera privata nycklar mellan system enbart för att förenkla en migrering. Ge varje trust relation egna kontrollerade credentials och planera rotation innan certifikaten löper ut.
Så stödjer FoxIDs bridgen
FoxIDs implementerar protocol bridging genom den vanliga modellen för applications och authentication methods. Det finns ingen separat bridge service att installera. En OpenID Connect applikation kan använda SAML 2.0, OpenID Connect eller WS-Federation authentication methods, och en SAML 2.0 applikation kan använda samma externa källor.
Det ger applikationsteam ett FoxIDs identity provider kontrakt medan identity providers, partner och äldre system kan anslutas med de standarder de stödjer. FoxIDs ger också claim mapping, konfigurerbara authentication flows, MFA och separata miljöer för test och produktion.
Använd dokumentationen om protocol bridge för den exakta konfigurationsmodellen, authentication methods och application registrations. Om arbetet omfattar onboarding av applikationer, claim design, testning eller stegvis migrering beskriver FoxIDs Identity Integration den implementeringshjälp som finns från teamet bakom plattformen.
Slutsats
En SAML till OpenID Connect bridge är mest användbar när den låter applikationer och identity providers utvecklas oberoende utan att försvaga identitetskontraktet mellan dem.
Behandla bridgen som en avsiktlig trust gräns, inte som en osynlig tokenöversättare. När applikationskontraktet, assurance reglerna, inloggnings- och utloggningsbeteendet, produktionsbevisen, ansvaret och rollback är tydliga ger FoxIDs den standardbaserade implementeringsmodellen för att införa förändringen i kontrollerade steg.