Bridge SAML 2.0 / OpenID Connect

Per impostazione predefinita, FoxIDs e un bridge tra SAML 2.0 e OpenID Connect / OAuth 2.0 senza alcuna configurazione aggiuntiva.

Federated Identity Management (FIM) si concentra sul collegamento delle identita tra domini, mentre Single Sign-On (SSO) semplifica l'accesso tra applicazioni. FoxIDs supporta sia FIM sia SSO, e il bridge li rende possibili tra SAML 2.0 e OpenID Connect.

OpenID Connect (OIDC) e SAML 2.0 sono entrambi protocolli ampiamente usati per federazione delle identita, single sign-on (SSO) e autenticazione utente. Tuttavia, sono fondamentalmente diversi per struttura e progettazione. Talvolta puo essere necessario creare un bridge o integrare questi protocolli, ad esempio per permettere a un'applicazione che supporta OpenID Connect di funzionare con un identity provider (IdP) che supporta solo SAML 2.0.

Differenze principali tra i due tipi di protocollo:

• OIDC: costruito sopra OAuth 2.0, e un protocollo moderno pensato per applicazioni web e mobile con API RESTful. Usa JSON Web Token (JWT) per token di identita e access token.
• SAML 2.0: basato su XML e focalizzato su scenari SSO browser-based, spesso usato in ambienti enterprise. Usa assertion / token basati su XML.

Per collegare un sistema OpenID Connect con un sistema SAML 2.0, e necessario un layer di traduzione o bridge di protocollo. Questo puo essere ottenuto usando un intermediario che agisce sia come OpenID Connect Provider (OP) sia come SAML Service Provider (SP), o viceversa.

Se configuri un metodo di autenticazione SAML 2.0 verso un Identity Provider (IdP) esterno e colleghi la tua app come applicazione OpenID Connect, selezionando il metodo di autenticazione SAML 2.0, una richiesta di login dalla tua app viene instradata come richiesta di login SAML 2.0 esterna. La risposta di login SAML 2.0 viene quindi mappata in una risposta OpenID Connect per la tua app. I claim SAML 2.0 vengono automaticamente convertiti in claim JWT (OAuth 2.0).

L'opposto e ugualmente possibile, avviando la richiesta di login da una app registrazione applicativa SAML 2.0 e instradandola a un OpenID Provider (OP) esterno configurato come metodo di autenticazione OpenID Connect. Successivamente, la risposta viene convertita in una risposta SAML 2.0.

FoxIDs supporta il bridge di login, logout e single logout tra SAML 2.0 e OpenID Connect.

Un ambiente - un Identity Provider

Tutte le funzionalita di bridge possono essere combinate nello stesso ambiente. Questo consente a una app OpenID Connect di supportare il login sia tramite un metodo di autenticazione SAML 2.0 sia tramite OpenID Connect allo stesso tempo. L'app OpenID Connect puo selezionare il metodo di autenticazione in modo grammaticale oppure lasciare che l'utente scelga in una pagina di home realm discovery (HRD).

Si raccomanda di avere un'infrastruttura applicativa con client OpenID Connect abilitati e API OAuth 2.0 abilitate. Dove tutte le applicazioni (client e API) si fidano dello stesso Identity Provider (IdP) - un IdP e uguale a un ambiente FoxIDs. Usando la funzionalita bridge in FoxIDs, i token SAML 2.0 vengono mappati in ID token e access token che possono essere usati per autenticare app OpenID Connect e chiamare API esistenti.

Token exchange

Se a un utente viene concesso l'accesso a una app SAML 2.0 dopo un login riuscito con un Identity Provider (IdP) SAML 2.0 esterno, l'utente ottiene accesso all'app SAML 2.0 nel contesto di se stesso. Con zero trust (never trust, always verify), si richiederebbe di chiamare le API nel contesto dell'utente. Questo e possibile usando token exchange, dove il token SAML 2.0 puo essere scambiato con un access token che porta l'identita dell'utente finale. Successivamente, la tua API con OAuth 2.0 abilitato puo essere chiamata nel contesto dell'utente.

Mappature dei claim

FoxIDs usa claim JWT internamente e mappa i claim SAML 2.0 in claim JWT. Per impostazione predefinita viene mappato un insieme di claim standard da JWT a SAML 2.0, ad esempio sub in http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, email in http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress, ecc. E possibile aggiungere ulteriori mappature da claim JWT a claim SAML 2.0.
Se non esiste una mappatura per un determinato claim, il nome lungo del claim SAML 2.0 viene mantenuto dai claim ricevuti in un token SAML 2.0 invece di usare un nome claim JWT equivalente piu corto. Lo stesso vale nella direzione opposta.