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.

Nogle teams beskriver dette som protocol translation, SAML til OIDC oversættelse, token translation, identity broker eller federation broker. I FoxIDs beskriver disse ord den samme konfigurationsmodel, men designet bør stadig gennemgås som en identity trust-grænse. Det vigtige resultat er ikke kun oversatte beskeder eller tokens, men en konsistent applikationskontrakt, issuer, audience, claims og logout-adfærd på tværs af de forbundne standarder.

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ø.

  1. Konfigurer den upstream identity provider som en autentificeringsmetode:
  2. Konfigurer applikationen som en application registration:
  3. Vælg den autentificeringsmetode i application registration, som skal håndtere login.
  4. 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.
  5. 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

Læs SAML til OIDC bridge for OpenID Connect applikationer for vejledning om arkitektur, claim-design, migrering og produktionsmodenhed.

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.

Tildelingskortlægning

FoxIDs bruger JWT-krav internt og kortlægger SAML 2.0-krav til JWT-krav. Den samme SAML/JWT-kravkortlægningsmodel bruges også til WS-Federation, fordi WS-Federation-tokens indeholder SAML-krav.

Som standard anvendes standardmappinger, 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 gennemgå og konfigurere claim-mappinger under fanen Indstillinger > Claim-mappinger i miljøet, som beskrevet under miljøindstillinger. Hvis der ikke findes en mappning for et claim, beholder FoxIDs det oprindelige claim-navn. Dette bevarer claims på tværs af broen, samtidig med at det stadig tillader kortere JWT claim-navne, hvor der er konfigureret mappinger.

Brugerdefinerede tilknytninger

Brugerdefinerede tilknytninger hører til miljøet og kobler en JWT-kravtype sammen med en SAML-kravtype. En brugerdefineret tilknytning har forrang for en ændringsbar standardindstilling for den samme indgående kravtype, men den kan ikke tilsidesætte en låst standardtilknytning.

Når Opret automatisk mappinger mellem JWT og SAML-kravtyper er aktiveret i miljøindstillingerne, kan FoxIDs tilføje brugerdefinerede mappinger for tidligere umappede kravtyper, efterhånden som de behandles. Du kan også tilføje, redigere eller fjerne brugerdefinerede mappinger manuelt.

Standardtilknytninger

Standardmappingerne SAML 2.0 og JWT er indbygget i FoxIDs og er skrivebeskyttede i Control Client. Låste standardmappinger håndhæves altid. Ændringsbare standardmappinger anvendes kun, når ingen brugerdefineret mapping har forrang for den indgående claim-type.