SAML 2.0, OpenID Connect og WS-Federation bro

FoxIDs kan fungere som en protokollbro mellom SAML 2.0, OpenID Connect / OAuth 2.0 og WS-Federation. Dette lar en applikasjon fortsette å bruke én identitetsprotokoll mens den eksterne identity provideren eller partnerapplikasjonen bruker en annen.

Broen er ikke en separat komponent som må installeres. Det er den normale FoxIDs-modellen: brukere logger inn via en autentiseringsmetode, og FoxIDs utsteder svaret som application registration krever. Når de to sidene bruker ulike standarder, håndterer FoxIDs protokolloversettelse, claim mapping, tokenoppretting og innloggingsruting.

Bruk broen når:

En applikasjon allerede støtter OpenID Connect og må logge inn brukere fra en SAML 2.0- eller WS-Federation identity provider.
En SAML 2.0- eller WS-Federation-applikasjon må bruke en OpenID Connect identity provider.
En eldre WS-Federation- eller SAML 2.0-applikasjon skal kobles til en moderne OpenID Connect-identitetsplattform uten å endre applikasjonen.
Flere applikasjoner skal stole på samme FoxIDs-miljø selv om de bruker ulike standarder.

Federated Identity Management (FIM) kobler identiteter på tvers av domener. Single Sign-On (SSO) lar brukere få tilgang til applikasjoner uten å logge inn på nytt. FoxIDs støtter begge deler, og broen får FIM og SSO til å fungere på tvers av protokollgrenser.

Slik fungerer broen

OpenID Connect, SAML 2.0 og WS-Federation løser mange av de samme identitetsoppgavene, men meldinger, tokens, metadata, sertifikater og claim-formater er forskjellige.

OpenID Connect bygger på OAuth 2.0 og brukes ofte av moderne web-, mobil- og API-baserte applikasjoner. Den bruker JSON Web Tokens (JWT-er) som identity tokens og access tokens.
SAML 2.0 er XML-basert og brukes mye til enterprise browserbasert SSO. Den bruker SAML assertions og XML-signaturer.
WS-Federation er XML-basert og brukes ofte av enterprise- og legacy-webapplikasjoner. Den bruker vanligvis SAML 1.1- eller SAML 2.0-tokens i WS-Federation innloggingssvar.

FoxIDs bygger bro mellom standardene ved å fungere som den betrodde parten på begge sider av forbindelsen:

Mot den eksterne identity provideren konfigureres FoxIDs som en autentiseringsmetode.
Mot applikasjonen konfigureres FoxIDs som en application registration.
Internt representerer FoxIDs claims som JWT claims og mapper mellom JWT claims og SAML claims ved behov.
Applikasjonen mottar protokollsvaret den allerede forstår.

Det er ikke noe krav om at inngående og utgående protokoll er den samme. En OpenID Connect-applikasjon kan bruke en SAML 2.0-autentiseringsmetode. En SAML 2.0-applikasjon kan bruke en OpenID Connect-autentiseringsmetode. WS-Federation kan også brukes på begge sider.

Konfigurer en bro

En bro konfigureres ved å kombinere en autentiseringsmetode med en application registration i samme miljø.

Konfigurer upstream identity provider som en autentiseringsmetode:
- OpenID Connect-autentiseringsmetode
- SAML 2.0-autentiseringsmetode
- WS-Federation-autentiseringsmetode
Konfigurer applikasjonen som en application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Velg autentiseringsmetoden i application registration som skal håndtere innlogging.
Hvis mer enn én autentiseringsmetode er tilgjengelig, kan applikasjonen velge en direkte, eller brukeren kan velge på en home realm discovery (HRD)-side.
Gå gjennom claim mappings, sertifikater, metadata og logout-atferd for standardene som brukes på hver side.

Det viktigste konfigurasjonsvalget er derfor ikke en egen bridge-innstilling. Det er koblingen mellom autentiseringsmetode og application registration.

SAML 2.0 til OpenID Connect

Denne broen er vanlig når en applikasjon allerede støtter OpenID Connect, men organisasjonen eller partnerens identity provider bare støtter SAML 2.0.

Konfigurer den eksterne IdP-en som en SAML 2.0-autentiseringsmetode. Konfigurer applikasjonen som en OpenID Connect application registration, og velg SAML 2.0-autentiseringsmetoden.

Når applikasjonen sender en OpenID Connect innloggingsforespørsel, ruter FoxIDs brukeren til den eksterne SAML 2.0 IdP-en. SAML 2.0-svaret valideres, SAML 2.0 claims mappes til JWT claims, og FoxIDs returnerer et OpenID Connect-svar til applikasjonen.

Bro SAML 2.0 til OpenID Connect

OpenID Connect til SAML 2.0

Denne broen er nyttig når en SAML 2.0-applikasjon skal bruke en moderne OpenID Connect identity provider.

Konfigurer den eksterne provideren som en OpenID Connect-autentiseringsmetode. Konfigurer applikasjonen som en SAML 2.0 application registration, og velg OpenID Connect-autentiseringsmetoden.

Når SAML 2.0-applikasjonen sender en SAML 2.0 Authn Request, ruter FoxIDs brukeren til OpenID Provider (OP). OpenID Connect-svaret valideres, JWT claims mappes til SAML 2.0 claims, og FoxIDs returnerer et SAML 2.0-svar til applikasjonen.

Bro OpenID Connect til SAML 2.0

FoxIDs støtter bro for innlogging, logout og single logout mellom SAML 2.0 og OpenID Connect.

WS-Federation bridge-scenarier

WS-Federation fungerer etter samme modell som de andre standardene. Den kan konfigureres som en autentiseringsmetode når den eksterne identity provideren er en WS-Federation Security Token Service (STS), og som en application registration når applikasjonen forventer et WS-Federation innloggingssvar.

Typiske WS-Federation bridge-scenarier er:

WS-Federation IdP til OpenID Connect-applikasjon.
OpenID Connect IdP til WS-Federation-applikasjon.
WS-Federation IdP til SAML 2.0-applikasjon.
SAML 2.0 IdP til WS-Federation-applikasjon.

Dette er nyttig ved AD FS-erstatning, eldre ASP.NET-applikasjoner, SharePoint, Dynamics og andre systemer som fortsatt bruker WS-Federation, mens nye applikasjoner og API-er kan fortsette å bruke OpenID Connect og OAuth 2.0.

Ett miljø, én Identity Provider

All bridge-funksjonalitet kan kombineres i samme FoxIDs-miljø. For eksempel kan en OpenID Connect-applikasjon støtte innlogging via både SAML 2.0- og OpenID Connect-autentiseringsmetoder samtidig.

Det er ofte enklere å la applikasjoner og API-er stole på ett FoxIDs-miljø som sin Identity Provider (IdP), selv om brukere autentiseres via ulike eksterne protokoller. I den modellen:

Registreres applikasjoner i FoxIDs med protokollen de allerede støtter.
Konfigureres eksterne identity providere som autentiseringsmetoder.
Utfører FoxIDs protokolloversettelse og claim mapping mellom de to sidene.
Kan OpenID Connect-klienter og OAuth 2.0-API-er fortsette å bruke ID tokens og access tokens, selv når den opprinnelige innloggingen kom fra SAML 2.0 eller WS-Federation.

Denne modellen er særlig nyttig når et applikasjonslandskap moderniseres gradvis. Eksisterende SAML 2.0- og WS-Federation-systemer kan fortsette å kjøre mens nye applikasjoner bruker OpenID Connect og OAuth 2.0.

Token exchange

Hvis en bruker logger inn i en SAML 2.0-applikasjon via en ekstern SAML 2.0 IdP, mottar applikasjonen et SAML 2.0-token for den brukeren. I zero trust-arkitekturer bør API-er fortsatt kalles i sluttbrukerens kontekst.

Bruk token exchange når et SAML 2.0-token må byttes til et OAuth 2.0 access token. Det resulterende access token kan brukes til å kalle OAuth 2.0-aktiverte API-er i konteksten til den innloggede brukeren.

Claim mappings

FoxIDs bruker JWT claims internt og mapper SAML 2.0 claims til JWT claims. Den samme SAML/JWT claim mapping-modellen brukes også for WS-Federation, fordi WS-Federation-tokens inneholder SAML claims.

Som standard brukes standardmappings, for eksempel sub til http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier og email til http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Du kan legge til flere JWT til SAML claim mappings i FoxIDs Control. Hvis det ikke finnes en mapping for en claim, beholder FoxIDs det opprinnelige claim-navnet. Dette bevarer claims på tvers av broen, samtidig som kortere JWT claim-navn kan brukes der mappings er konfigurert.