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.

Noen team beskriver dette som protocol translation, SAML til OIDC oversettelse, token translation, identity broker eller federation broker. I FoxIDs beskriver disse ordene den samme konfigurasjonsmodellen, men designet bør fortsatt gjennomgås som en identity trust-grense. Det viktige resultatet er ikke bare oversatte meldinger eller tokens, men en konsistent applikasjonskontrakt, issuer, audience, claims og utloggingsatferd på tvers av de tilkoblede standardene.

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

  1. Konfigurer upstream identity provider som en autentiseringsmetode:
  2. Konfigurer applikasjonen som en application registration:
  3. Velg autentiseringsmetoden i application registration som skal håndtere innlogging.
  4. Hvis mer enn én autentiseringsmetode er tilgjengelig, kan applikasjonen velge en direkte, eller brukeren kan velge på en home realm discovery (HRD)-side.
  5. 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

Les SAML til OIDC bridge for OpenID Connect applikasjoner for veiledning om arkitektur, claim-design, migrering og produksjonsberedskap.

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.

Tilordning av krav

FoxIDs bruker JWT-påstander internt og tilordner SAML 2.0-påstander til JWT-påstander. Den samme modellen for tilordning av SAML/JWT-påstander brukes også for WS-Federation, fordi WS-Federation-tokens inneholder SAML-påstander.

Som standard brukes standardtilordninger, 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 se gjennom og konfigurere tilordninger av krav i miljøets Innstillinger > Tilordninger av krav-fanen, beskrevet under miljøinnstillinger. Hvis det ikke finnes noen tilordning for et krav, beholder FoxIDs det opprinnelige kravnavnet. Dette bevarer kravene over broen, samtidig som det tillater kortere JWT kravnavn der tilordninger er konfigurert.

Tilpassede tilordninger

Tilpassede tilordninger tilhører miljøet og kobler en JWT-kravtype til en SAML-kravtype. En tilpasset tilordning har forrang fremfor en endringsbar standard for den samme innkommende kravtypen, men den kan ikke overstyre en låst standardtilordning.

Når Opprett automatisk tilordninger mellom JWT og SAML-kravtyper er aktivert i miljøinnstillingene, kan FoxIDs legge til egendefinerte tilordninger for kravtyper som ikke tidligere er tilordnet, etter hvert som de behandles. Du kan også legge til, redigere eller fjerne egendefinerte tilordninger manuelt.

Standardtilordninger

Standard SAML 2.0 og JWT tilordninger av påstander er innebygd i FoxIDs og er skrivebeskyttet i Control Client. Låste standardtilordninger håndheves alltid. Endringsbare standardtilordninger brukes kun når ingen tilpasset tilordning har forrang for den innkommende påstandstypen.