SAML 2.0, OpenID Connect och WS-Federation brygga

FoxIDs kan fungera som en protokollbrygga mellan SAML 2.0, OpenID Connect / OAuth 2.0 och WS-Federation. Det låter en applikation fortsätta använda ett identitetsprotokoll medan den externa identity providern eller partnerapplikationen använder ett annat.

Bryggan är inte en separat komponent som måste installeras. Det är den normala FoxIDs-modellen: användare loggar in via en autentiseringsmetod, och FoxIDs utfärdar svaret som application registration kräver. När de två sidorna använder olika standarder hanterar FoxIDs protokollöversättning, claim mapping, tokenutfärdande och inloggningsroutning.

Använd bryggan när:

En applikation redan stöder OpenID Connect och behöver logga in användare från en SAML 2.0- eller WS-Federation identity provider.
En SAML 2.0- eller WS-Federation-applikation behöver använda en OpenID Connect identity provider.
En äldre WS-Federation- eller SAML 2.0-applikation ska kopplas till en modern OpenID Connect-identitetsplattform utan att applikationen ändras.
Flera applikationer ska lita på samma FoxIDs-miljö även om de använder olika standarder.

Federated Identity Management (FIM) kopplar identiteter över domängränser. Single Sign-On (SSO) låter användare komma åt applikationer utan att logga in igen. FoxIDs stöder båda, och bryggan gör att FIM och SSO fungerar över protokollgränser.

Så fungerar bryggan

OpenID Connect, SAML 2.0 och WS-Federation löser många av samma identitetsproblem, men deras meddelanden, tokens, metadata, certifikat och claim-format är olika.

OpenID Connect bygger på OAuth 2.0 och används ofta av moderna webb-, mobil- och API-baserade applikationer. Den använder JSON Web Tokens (JWT:er) som identity tokens och access tokens.
SAML 2.0 är XML-baserat och används brett för enterprise browserbaserad SSO. Den använder SAML assertions och XML-signaturer.
WS-Federation är XML-baserat och används ofta av enterprise- och legacy-webbapplikationer. Den använder vanligtvis SAML 1.1- eller SAML 2.0-tokens i WS-Federation inloggningssvar.

FoxIDs bygger brygga mellan standarderna genom att fungera som betrodd part på båda sidor av anslutningen:

Mot den externa identity providern konfigureras FoxIDs som en autentiseringsmetod.
Mot applikationen konfigureras FoxIDs som en application registration.
Internt representerar FoxIDs claims som JWT claims och mappar mellan JWT claims och SAML claims vid behov.
Applikationen får protokollsvaret den redan förstår.

Det finns inget krav på att inkommande och utgående protokoll är samma. En OpenID Connect-applikation kan använda en SAML 2.0-autentiseringsmetod. En SAML 2.0-applikation kan använda en OpenID Connect-autentiseringsmetod. WS-Federation kan också användas på båda sidor.

Konfigurera en brygga

En brygga konfigureras genom att kombinera en autentiseringsmetod med en application registration i samma miljö.

Konfigurera upstream identity provider som en autentiseringsmetod:
- OpenID Connect-autentiseringsmetod
- SAML 2.0-autentiseringsmetod
- WS-Federation-autentiseringsmetod
Konfigurera applikationen som en application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Välj den autentiseringsmetod i application registration som ska hantera inloggning.
Om fler än en autentiseringsmetod är tillgänglig kan applikationen välja en direkt, eller användaren kan välja på en home realm discovery (HRD)-sida.
Granska claim mappings, certifikat, metadata och logout-beteende för standarderna som används på varje sida.

Det viktigaste konfigurationsvalet är därför inte en särskild bridge-inställning. Det är kopplingen mellan autentiseringsmetod och application registration.

SAML 2.0 till OpenID Connect

Den här bryggan är vanlig när en applikation redan stöder OpenID Connect, men organisationens eller partnerns identity provider bara stöder SAML 2.0.

Konfigurera den externa IdP:n som en SAML 2.0-autentiseringsmetod. Konfigurera applikationen som en OpenID Connect application registration, och välj SAML 2.0-autentiseringsmetoden.

När applikationen skickar en OpenID Connect inloggningsbegäran routar FoxIDs användaren till den externa SAML 2.0 IdP:n. SAML 2.0-svaret valideras, SAML 2.0 claims mappas till JWT claims, och FoxIDs returnerar ett OpenID Connect-svar till applikationen.

Brygga SAML 2.0 till OpenID Connect

OpenID Connect till SAML 2.0

Den här bryggan är användbar när en SAML 2.0-applikation ska använda en modern OpenID Connect identity provider.

Konfigurera den externa providern som en OpenID Connect-autentiseringsmetod. Konfigurera applikationen som en SAML 2.0 application registration, och välj OpenID Connect-autentiseringsmetoden.

När SAML 2.0-applikationen skickar en SAML 2.0 Authn Request routar FoxIDs användaren till OpenID Provider (OP). OpenID Connect-svaret valideras, JWT claims mappas till SAML 2.0 claims, och FoxIDs returnerar ett SAML 2.0-svar till applikationen.

Brygga OpenID Connect till SAML 2.0

FoxIDs stöder brygga för inloggning, logout och single logout mellan SAML 2.0 och OpenID Connect.

WS-Federation bridge-scenarier

WS-Federation fungerar enligt samma modell som de andra standarderna. Den kan konfigureras som en autentiseringsmetod när den externa identity providern är en WS-Federation Security Token Service (STS), och som en application registration när applikationen förväntar sig ett WS-Federation inloggningssvar.

Typiska WS-Federation bridge-scenarier är:

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

Detta är användbart vid AD FS-ersättning, äldre ASP.NET-applikationer, SharePoint, Dynamics och andra system som fortfarande använder WS-Federation, medan nya applikationer och API:er kan fortsätta använda OpenID Connect och OAuth 2.0.

En miljö, en Identity Provider

All bridge-funktionalitet kan kombineras i samma FoxIDs-miljö. Till exempel kan en OpenID Connect-applikation stödja inloggning via både SAML 2.0- och OpenID Connect-autentiseringsmetoder samtidigt.

Det är ofta enklare att låta applikationer och API:er lita på en FoxIDs-miljö som sin Identity Provider (IdP), även om användare autentiseras via olika externa protokoll. I den modellen:

Registreras applikationer i FoxIDs med protokollet de redan stöder.
Konfigureras externa identity providers som autentiseringsmetoder.
Utför FoxIDs protokollöversättning och claim mapping mellan de två sidorna.
Kan OpenID Connect-klienter och OAuth 2.0-API:er fortsätta använda ID tokens och access tokens, även när den ursprungliga inloggningen kom från SAML 2.0 eller WS-Federation.

Den här modellen är särskilt användbar när ett applikationslandskap moderniseras stegvis. Befintliga SAML 2.0- och WS-Federation-system kan fortsätta köra medan nya applikationer använder OpenID Connect och OAuth 2.0.

Token exchange

Om en användare loggar in i en SAML 2.0-applikation via en extern SAML 2.0 IdP får applikationen ett SAML 2.0-token för den användaren. I zero trust-arkitekturer bör API:er fortfarande anropas i slutanvändarens kontext.

Använd token exchange när ett SAML 2.0-token behöver bytas mot ett OAuth 2.0 access token. Det resulterande access token kan användas för att anropa OAuth 2.0-aktiverade API:er i den inloggade användarens kontext.

Claim mappings

FoxIDs använder JWT claims internt och mappar SAML 2.0 claims till JWT claims. Samma SAML/JWT claim mapping-modell används också för WS-Federation, eftersom WS-Federation-tokens innehåller SAML claims.

Som standard används standardmappningar, till exempel sub till http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier och email till http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

Du kan lägga till ytterligare JWT till SAML claim mappings i FoxIDs Control. Om ingen mapping finns för en claim behåller FoxIDs det ursprungliga claim-namnet. Det bevarar claims över bryggan samtidigt som kortare JWT claim-namn kan användas där mappings är konfigurerade.