SAML 2.0, OpenID Connect og WS-Federation bro

FoxIDs kan fungere som en protokolbro mellem SAML 2.0, OpenID Connect / OAuth 2.0 og WS-Federation. Det lader en applikation fortsætte med at bruge én identitetsprotokol, mens den eksterne identity provider eller partnerapplikation bruger en anden.

Broen er ikke en separat komponent, der skal installeres. Det er den normale FoxIDs-model: brugere logger ind via en autentificeringsmetode, og FoxIDs udsteder det svar, som application registration kræver. Når de to sider bruger forskellige standarder, håndterer FoxIDs protokoloversættelse, claim mapping, tokenoprettelse og login-routing.

Brug broen når:

En applikation allerede understøtter OpenID Connect og skal logge brugere ind fra en SAML 2.0- eller WS-Federation identity provider.
En SAML 2.0- eller WS-Federation-applikation skal bruge en OpenID Connect identity provider.
En ældre WS-Federation- eller SAML 2.0-applikation skal forbindes til en moderne OpenID Connect-identitetsplatform uden at ændre applikationen.
Flere applikationer skal stole på det samme FoxIDs-miljø, selv om de bruger forskellige standarder.

Federeret identitetsstyring (FIM) forbinder identiteter på tværs af domæner. Single Sign-On (SSO) lader brugere få adgang til applikationer uden at logge ind igen. FoxIDs understøtter begge dele, og broen får FIM og SSO til at fungere på tværs af protokolgrænser.

Sådan fungerer broen

OpenID Connect, SAML 2.0 og WS-Federation løser mange af de samme identitetsopgaver, men deres beskeder, tokens, metadata, certifikater og claim-formater er forskellige.

OpenID Connect bygger på OAuth 2.0 og bruges ofte af moderne web-, mobil- og API-baserede applikationer. Den bruger JSON Web Tokens (JWT'er) som identity tokens og access tokens.
SAML 2.0 er XML-baseret og bruges bredt til enterprise browserbaseret SSO. Den bruger SAML assertions og XML-signaturer.
WS-Federation er XML-baseret og bruges ofte af enterprise- og legacy-webapplikationer. Den bruger typisk SAML 1.1- eller SAML 2.0-tokens i WS-Federation login-svar.

FoxIDs bygger bro mellem standarderne ved at fungere som den betroede part på begge sider af forbindelsen:

Mod den eksterne identity provider konfigureres FoxIDs som en autentificeringsmetode.
Mod applikationen konfigureres FoxIDs som en application registration.
Internt repræsenterer FoxIDs claims som JWT claims og mapper mellem JWT claims og SAML claims efter behov.
Applikationen modtager det protokolsvar, den allerede forstår.

Der er ikke noget krav om, at den indgående og udgående protokol er den samme. En OpenID Connect-applikation kan bruge en SAML 2.0-autentificeringsmetode. En SAML 2.0-applikation kan bruge en OpenID Connect-autentificeringsmetode. WS-Federation kan også bruges på begge sider.

Konfigurer en bro

En bro konfigureres ved at kombinere en autentificeringsmetode med en application registration i samme miljø.

Konfigurer den upstream identity provider som en autentificeringsmetode:
- OpenID Connect-autentificeringsmetode
- SAML 2.0-autentificeringsmetode
- WS-Federation-autentificeringsmetode
Konfigurer applikationen som en application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Vælg den autentificeringsmetode i application registration, som skal håndtere login.
Hvis mere end én autentificeringsmetode er tilgængelig, kan applikationen vælge en direkte, eller brugeren kan vælge på en home realm discovery (HRD)-side.
Gennemgå claim mappings, certifikater, metadata og logout-adfærd for de standarder, der bruges på hver side.

Det vigtigste konfigurationsvalg er derfor ikke en særlig bridge-indstilling. Det er koblingen mellem autentificeringsmetode og application registration.

SAML 2.0 til OpenID Connect

Denne bro er almindelig, når en applikation allerede understøtter OpenID Connect, men organisationen eller partnerens identity provider kun understøtter SAML 2.0.

Konfigurer den eksterne IdP som en SAML 2.0-autentificeringsmetode. Konfigurer applikationen som en OpenID Connect application registration, og vælg SAML 2.0-autentificeringsmetoden.

Når applikationen sender en OpenID Connect login-request, router FoxIDs brugeren til den eksterne SAML 2.0 IdP. SAML 2.0-svaret valideres, SAML 2.0 claims mappes til JWT claims, og FoxIDs returnerer et OpenID Connect-svar til applikationen.

Bro SAML 2.0 til OpenID Connect

OpenID Connect til SAML 2.0

Denne bro er nyttig, når en SAML 2.0-applikation skal bruge en moderne OpenID Connect identity provider.

Konfigurer den eksterne provider som en OpenID Connect-autentificeringsmetode. Konfigurer applikationen som en SAML 2.0 application registration, og vælg OpenID Connect-autentificeringsmetoden.

Når SAML 2.0-applikationen sender en SAML 2.0 Authn Request, router FoxIDs brugeren 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 applikationen.

Bro OpenID Connect til SAML 2.0

FoxIDs understøtter bro for login, logout og single logout mellem SAML 2.0 og OpenID Connect.

WS-Federation bridge-scenarier

WS-Federation fungerer efter samme model som de andre standarder. Den kan konfigureres som en autentificeringsmetode, når den eksterne identity provider er en WS-Federation Security Token Service (STS), og som en application registration, når applikationen forventer et WS-Federation login-svar.

Typiske WS-Federation bridge-scenarier er:

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

Det er nyttigt ved AD FS-erstatning, ældre ASP.NET-applikationer, SharePoint, Dynamics og andre systemer, der stadig bruger WS-Federation, mens nye applikationer og API'er kan fortsætte med at bruge OpenID Connect og OAuth 2.0.

Ét miljø, én Identity Provider

Al bridge-funktionalitet kan kombineres i samme FoxIDs-miljø. For eksempel kan en OpenID Connect-applikation understøtte login via både SAML 2.0- og OpenID Connect-autentificeringsmetoder på samme tid.

Det er ofte enklere at lade applikationer og API'er stole på ét FoxIDs-miljø som deres Identity Provider (IdP), selv om brugere autentificeres via forskellige eksterne protokoller. I den model:

Registreres applikationer i FoxIDs med den protokol, de allerede understøtter.
Konfigureres eksterne identity providere som autentificeringsmetoder.
Udfører FoxIDs protokoloversættelse og claim mapping mellem de to sider.
Kan OpenID Connect-klienter og OAuth 2.0-API'er fortsætte med at bruge ID tokens og access tokens, selv når det oprindelige login kom fra SAML 2.0 eller WS-Federation.

Denne model er især nyttig, når et applikationslandskab moderniseres gradvist. Eksisterende SAML 2.0- og WS-Federation-systemer kan fortsætte med at køre, mens nye applikationer bruger OpenID Connect og OAuth 2.0.

Token exchange

Hvis en bruger logger ind i en SAML 2.0-applikation via en ekstern SAML 2.0 IdP, modtager applikationen et SAML 2.0-token for den bruger. I zero trust-arkitekturer bør API'er stadig kaldes i slutbrugerens kontekst.

Brug token exchange, når et SAML 2.0-token skal udveksles til et OAuth 2.0 access token. Det resulterende access token kan bruges til at kalde OAuth 2.0-aktiverede API'er i konteksten af den bruger, der er logget ind.

Claim mappings

FoxIDs bruger JWT claims internt og mapper SAML 2.0 claims til JWT claims. Den samme SAML/JWT claim mapping-model bruges også til WS-Federation, fordi WS-Federation-tokens indeholder SAML claims.

Som standard anvendes 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 tilføje yderligere JWT til SAML claim mappings i FoxIDs Control. Hvis der ikke findes en mapping for en claim, beholder FoxIDs det oprindelige claim-navn. Det bevarer claims på tværs af broen, samtidig med at kortere JWT claim-navne kan bruges, hvor mappings er konfigureret.