Bridge SAML 2.0, OpenID Connect e WS-Federation

FoxIDs può agire come bridge di protocolli tra SAML 2.0, OpenID Connect / OAuth 2.0 e WS-Federation. Questo permette a un’applicazione di continuare a usare un protocollo di identità mentre l’identity provider esterno o l’applicazione partner ne usa un altro.

Il bridge non è un componente separato da installare. È il normale modello FoxIDs: gli utenti accedono tramite un metodo di autenticazione e FoxIDs emette la risposta richiesta dall’application registration. Quando i due lati usano standard diversi, FoxIDs gestisce traduzione dei protocolli, claim mapping, creazione dei token e routing del sign-in.

Alcuni team descrivono questo come protocol translation, traduzione SAML a OIDC, token translation, identity broker o federation broker. In FoxIDs questi termini descrivono lo stesso modello di configurazione, ma il design va comunque valutato come confine di identity trust. Il risultato importante non è solo la traduzione di messaggi o token, ma un contratto applicativo, issuer, audience, claims e comportamento di logout coerenti tra gli standard collegati.

Usa il bridge quando:

Un’applicazione supporta già OpenID Connect e deve autenticare utenti da un identity provider SAML 2.0 o WS-Federation.
Un’applicazione SAML 2.0 o WS-Federation deve usare un identity provider OpenID Connect.
Un’applicazione legacy WS-Federation o SAML 2.0 deve essere collegata a una piattaforma di identità OpenID Connect moderna senza modificare l’applicazione.
Più applicazioni devono considerare attendibile lo stesso ambiente FoxIDs anche se usano standard diversi.

Federated Identity Management (FIM) collega identità tra domini. Single Sign-On (SSO) consente agli utenti di accedere alle applicazioni senza effettuare nuovamente il login. FoxIDs supporta entrambi, e il bridge fa funzionare FIM e SSO oltre i confini dei protocolli.

Come funziona il bridge

OpenID Connect, SAML 2.0 e WS-Federation risolvono molti degli stessi problemi di identità, ma messaggi, token, metadata, certificati e formati dei claims sono diversi.

OpenID Connect si basa su OAuth 2.0 ed è comunemente usato da applicazioni web, mobile e basate su API moderne. Usa JSON Web Tokens (JWT) come identity tokens e access tokens.
SAML 2.0 è basato su XML ed è ampiamente usato per SSO enterprise basato su browser. Usa SAML assertions e firme XML.
WS-Federation è basato su XML ed è comunemente usato da applicazioni web enterprise e legacy. In genere usa token SAML 1.1 o SAML 2.0 nelle risposte di sign-in WS-Federation.

FoxIDs crea un bridge tra questi standard agendo come parte attendibile su entrambi i lati della connessione:

Verso l’identity provider esterno, FoxIDs è configurato come metodo di autenticazione.
Verso l’applicazione, FoxIDs è configurato come application registration.
Internamente, FoxIDs rappresenta i claims come JWT claims e mappa tra JWT claims e SAML claims quando necessario.
L’applicazione riceve la risposta di protocollo che già comprende.

Non è richiesto che il protocollo in ingresso e quello in uscita siano uguali. Un’applicazione OpenID Connect può usare un metodo di autenticazione SAML 2.0. Un’applicazione SAML 2.0 può usare un metodo di autenticazione OpenID Connect. Anche WS-Federation può essere usato su entrambi i lati.

Configurare un bridge

Un bridge si configura combinando un metodo di autenticazione con un’application registration nello stesso ambiente.

Configura l’identity provider upstream come metodo di autenticazione:
- Metodo di autenticazione OpenID Connect
- Metodo di autenticazione SAML 2.0
- Metodo di autenticazione WS-Federation
Configura l’applicazione come application registration:
- OpenID Connect application registration
- SAML 2.0 application registration
- WS-Federation application registration
Nell’application registration, seleziona il metodo di autenticazione che deve gestire il sign-in.
Se sono disponibili più metodi di autenticazione, l’applicazione può selezionarne uno direttamente oppure l’utente può scegliere in una pagina home realm discovery (HRD).
Verifica claim mappings, certificati, metadata e comportamento di logout per gli standard usati su ciascun lato.

La scelta di configurazione più importante non è quindi una speciale impostazione bridge. È l’associazione tra metodo di autenticazione e application registration.

Da SAML 2.0 a OpenID Connect

Questo bridge è comune quando un’applicazione supporta già OpenID Connect, ma l’organizzazione o l’identity provider partner supporta solo SAML 2.0.

Configura l’IdP esterno come metodo di autenticazione SAML 2.0. Configura l’applicazione come OpenID Connect application registration e seleziona il metodo di autenticazione SAML 2.0.

Quando l’applicazione invia una richiesta di sign-in OpenID Connect, FoxIDs instrada l’utente all’IdP SAML 2.0 esterno. La risposta SAML 2.0 viene validata, i SAML 2.0 claims vengono mappati a JWT claims e FoxIDs restituisce una risposta OpenID Connect all’applicazione.

Bridge da SAML 2.0 a OpenID Connect

Leggi Bridge da SAML a OIDC per applicazioni OpenID Connect per indicazioni su architettura, progettazione dei claims, migrazione e preparazione alla produzione.

Da OpenID Connect a SAML 2.0

Questo bridge è utile quando un’applicazione SAML 2.0 deve usare un identity provider OpenID Connect moderno.

Configura il provider esterno come metodo di autenticazione OpenID Connect. Configura l’applicazione come SAML 2.0 application registration e seleziona il metodo di autenticazione OpenID Connect.

Quando l’applicazione SAML 2.0 invia una SAML 2.0 Authn Request, FoxIDs instrada l’utente all’OpenID Provider (OP). La risposta OpenID Connect viene validata, i JWT claims vengono mappati a SAML 2.0 claims e FoxIDs restituisce una risposta SAML 2.0 all’applicazione.

Bridge da OpenID Connect a SAML 2.0

FoxIDs supporta il bridging di sign-in, logout e single logout tra SAML 2.0 e OpenID Connect.

Scenari bridge WS-Federation

WS-Federation funziona con lo stesso modello degli altri standard. Può essere configurato come metodo di autenticazione quando l’identity provider esterno è un WS-Federation Security Token Service (STS), e come application registration quando l’applicazione si aspetta una risposta di sign-in WS-Federation.

Scenari bridge WS-Federation tipici includono:

IdP WS-Federation verso applicazione OpenID Connect.
IdP OpenID Connect verso applicazione WS-Federation.
IdP WS-Federation verso applicazione SAML 2.0.
IdP SAML 2.0 verso applicazione WS-Federation.

Questo è utile per scenari di sostituzione AD FS, applicazioni ASP.NET più vecchie, SharePoint, Dynamics e altri sistemi che usano ancora WS-Federation, mentre nuove applicazioni e API possono continuare a usare OpenID Connect e OAuth 2.0.

Un ambiente, un Identity Provider

Tutte le funzionalità bridge possono essere combinate nello stesso ambiente FoxIDs. Ad esempio, un’applicazione OpenID Connect può supportare il sign-in tramite metodi di autenticazione SAML 2.0 e OpenID Connect contemporaneamente.

Spesso è più semplice far sì che applicazioni e API considerino attendibile un solo ambiente FoxIDs come Identity Provider (IdP), anche se gli utenti si autenticano tramite protocolli esterni diversi. In questo modello:

Le applicazioni sono registrate in FoxIDs con il protocollo che già supportano.
Gli identity provider esterni sono configurati come metodi di autenticazione.
FoxIDs esegue traduzione dei protocolli e claim mapping tra i due lati.
Client OpenID Connect e API OAuth 2.0 possono continuare a usare ID tokens e access tokens, anche quando il sign-in originale proviene da SAML 2.0 o WS-Federation.

Questo modello è particolarmente utile quando un panorama applicativo viene modernizzato gradualmente. I sistemi SAML 2.0 e WS-Federation esistenti possono continuare a funzionare mentre le nuove applicazioni usano OpenID Connect e OAuth 2.0.

Token exchange

Se un utente accede a un’applicazione SAML 2.0 tramite un IdP SAML 2.0 esterno, l’applicazione riceve un token SAML 2.0 per quell’utente. Nelle architetture zero trust, le API dovrebbero comunque essere chiamate nel contesto dell’utente finale.

Usa token exchange quando un token SAML 2.0 deve essere scambiato con un access token OAuth 2.0. L’access token risultante può essere usato per chiamare API abilitate per OAuth 2.0 nel contesto dell’utente autenticato.

Mappature dei claim

FoxIDs utilizza internamente i claim JWT e mappa i claim SAML 2.0 ai claim JWT. Lo stesso modello di mappatura dei claim SAML/JWT viene utilizzato anche per WS-Federation, poiché i token WS-Federation contengono claim SAML.

Per impostazione predefinita, vengono applicate le mappature standard, ad esempio sub a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier e email a http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress.

È possibile visualizzare e configurare le mappature delle claim nella scheda Impostazioni > Mappature delle claim dell'ambiente, descritta nella sezione Impostazioni dell'ambiente. Se non esiste alcuna mappatura per una claim, FoxIDs mantiene il nome originale della claim. Ciò consente di preservare le claim attraverso il bridge, pur consentendo l'uso di nomi di claim più brevi JWT laddove sono configurate le mappature.

Mappature personalizzate

Le mappature personalizzate appartengono all'ambiente e associano un tipo di claim JWT a un tipo di claim SAML. Una mappatura personalizzata ha la precedenza su un valore predefinito modificabile per lo stesso tipo di claim in entrata, ma non può sovrascrivere una mappatura predefinita bloccata.

Quando l'opzione Crea automaticamente mappature tra i tipi di claim JWT e SAML è abilitata nelle impostazioni dell'ambiente, FoxIDs può aggiungere mappature personalizzate per i tipi di claim non ancora mappati man mano che vengono elaborati. È inoltre possibile aggiungere, modificare o rimuovere manualmente le mappature personalizzate.

Mappature predefinite

Le mappature predefinite SAML 2.0 e JWT sono integrate in FoxIDs e sono di sola lettura nel Control Client. Le mappature predefinite bloccate vengono sempre applicate. Le mappature predefinite modificabili vengono utilizzate solo quando nessuna mappatura personalizzata ha la precedenza per il tipo di claim in entrata.