SAML 2.0 / OpenID Connect bro

Som standard er FoxIDs en bro mellem SAML 2.0 og OpenID Connect / OAuth 2.0 uden ekstra konfiguration.

Federeret identitetsstyring (FIM) fokuserer på at forbinde identiteter på tværs af domæner, mens single sign-on (SSO) gør adgang på tværs af applikationer mere smidig. FoxIDs understøtter både FIM og SSO, og broen muliggør det på tværs af SAML 2.0 og OpenID Connect.

OpenID Connect (OIDC) og SAML 2.0 er begge udbredte protokoller til identitetsfederation, single sign on (SSO) og brugerautentificering. De er dog grundlæggende forskellige i struktur og design. Nogle gange skal du bygge bro mellem protokollerne, for eksempel når en applikation der understøtter OpenID Connect skal arbejde med en Identity Provider (IdP) som kun understøtter SAML 2.0.

Nøgleforskelle mellem de to protokoltyper:

• OIDC: Bygger ovenpå OAuth 2.0, er en moderne protokol til web og mobile apps med RESTful APIs. Bruger JSON Web Tokens (JWT) til identitetstokens og access tokens.
• SAML 2.0: XML baseret og fokuseret på browserbaserede SSO scenarier, ofte brugt i enterprise miljøer. Bruger XML baserede assertions / tokens.

For at forbinde et OpenID Connect system med et SAML 2.0 system skal du have et protokoloversættelses eller bro lag. Dette kan opnås med en mellemkomponent der fungerer som både OpenID Connect Provider (OP) og SAML Service Provider (SP) eller omvendt.

Hvis du konfigurerer en SAML 2.0 autentificeringsmetode til en ekstern Identity Provider (IdP) og forbinder din app som en OpenID Connect applikation, hvor du vælger SAML 2.0 autentificeringsmetoden, så bliver en login request fra din app routet som en ekstern SAML 2.0 login request. SAML 2.0 login responsen bliver efterfølgende mappet til en OpenID Connect respons til din app. SAML 2.0 claims bliver automatisk konverteret til JWT (OAuth 2.0) claims.

Det modsatte er også muligt ved at starte login requesten fra en SAML 2.0 application registration og route til en ekstern OpenID Provider (OP) konfigureret som en OpenID Connect autentificeringsmetode. Efterfølgende bliver responsen konverteret til en SAML 2.0 respons.

FoxIDs understøtter at bygge bro for både login, logout og single logout mellem SAML 2.0 og OpenID Connect.

Ét miljø - én Identity Provider

Al bro funktionalitet kan kombineres i samme miljø. Det gør det muligt for en OpenID Connect app at understøtte login via både en SAML 2.0 eller OpenID Connect autentificeringsmetode på samme tid. OpenID Connect appen kan enten vælge autentificeringsmetoden programmatisk eller lade brugeren vælge på en home realm discovery (HRD) side.

Det anbefales at have en applikationsinfrastruktur med OpenID Connect aktiverede klienter og OAuth 2.0 aktiverede API'er. Hvor alle applikationer (klienter og API'er) stoler på den samme Identity Provider (IdP) - én IdP er lig med ét miljø i FoxIDs. Ved at bruge bro funktionaliteten i FoxIDs bliver SAML 2.0 tokens mappet til ID tokens og access tokens som kan bruges til at autentificere OpenID Connect apps og kalde eksisterende API'er.

Token exchange

Hvis en bruger får adgang til en SAML 2.0 app efter succesfuld login med en ekstern SAML 2.0 Identity Provider (IdP), får brugeren adgang til SAML 2.0 appen i konteksten af sig selv. Med zero trust (aldrig tillid, altid verificer) vil du kræve at kalde dine API'er i brugerens kontekst. Det er muligt ved at bruge token exchange, hvor SAML 2.0 token kan udveksles til et access token med slutbrugerens identitet. Efterfølgende kan din OAuth 2.0 aktiverede API kaldes i brugerens kontekst.

Claim mappings

FoxIDs bruger JWT claims internt og mapper SAML 2.0 claims til JWT claims. Som standard mappes et sæt standard JWT til SAML 2.0 claims, f.eks. sub til http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email til http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress osv. Du kan tilføje yderligere JWT til SAML 2.0 claim mappings. Hvis der ikke findes en mapping for en bestemt claim, beholdes det lange SAML 2.0 claim navn fra claims modtaget i et SAML 2.0 token i stedet for et kortere tilsvarende JWT claim navn. Det samme gælder i den modsatte retning.