Un’applicazione e il relativo identity provider non devono necessariamente supportare lo stesso protocollo di federazione. Un’applicazione moderna può usare OpenID Connect mentre un identity provider aziendale o di un partner continua a usare SAML 2.0. Riscrivere uno dei due lati solo per uniformare i protocolli può aumentare costi, rischio di migrazione e dipendenze non necessarie.

Un bridge da SAML a OpenID Connect consente a ciascun lato di conservare il protocollo già supportato. FoxIDs convalida la risposta SAML 2.0 dell’identity provider esterno, applica i claims e le regole di sicurezza necessari ed emette la risposta OpenID Connect attesa dall’applicazione.

Le ricerche su questo problema usano spesso espressioni tecniche brevi come SAML a OIDC, OIDC bridge, SAML OIDC bridge, protocol bridge, traduzione dei protocolli, traduzione SAML a OIDC, token translation, identity broker o identity federation broker. La domanda architetturale resta la stessa: come può un’applicazione fidarsi di un contratto OpenID Connect moderno mentre un identity provider esistente, un partner o una vecchia applicazione SAML continua a usare il protocollo già supportato?

Non è una semplice conversione del formato del token. Un bridge efficace deve preservare identità, authentication assurance e contratto applicativo fra standard con formati dei messaggi, modelli di firma, sessioni e convenzioni dei claims differenti.

Quando il protocol bridging è il modello giusto

Il protocol bridging è utile quando crea un confine controllato fra sistemi che devono cambiare a velocità diverse.

Scenari tipici:

  • Una nuova applicazione web, mobile o single-page supporta OpenID Connect, ma clienti o partner si autenticano tramite identity providers SAML 2.0.
  • Applicazioni SAML 2.0 esistenti devono usare un identity provider OpenID Connect moderno.
  • Un’organizzazione sostituisce AD FS o un’altra piattaforma di federazione gradualmente, per esempio in una migrazione da AD FS a OpenID Connect, anziché modificare tutte le applicazioni insieme.
  • Più applicazioni devono considerare attendibile un unico livello di identità, anche se gli identity providers esterni usano protocolli diversi.
  • Una migrazione richiede ambienti paralleli di test e produzione e un percorso di rollback chiaro.

Se entrambi i lati supportano già lo stesso protocollo adatto e possono essere collegati in sicurezza, un bridge potrebbe non aggiungere valore. Usalo quando riduce l’accoppiamento o abilita un cambiamento graduale, non solo perché la traduzione è possibile.

Decidi subito se il bridge è una fase di migrazione o un componente architetturale duraturo. Un bridge temporaneo richiede criteri di uscita espliciti per rimuovere la precedente relazione di trust. Un bridge duraturo richiede responsabilità operative assegnate, monitoraggio e gestione del ciclo di vita dei certificati su entrambi i lati.

Scegli prima il contratto verso l’applicazione

Il protocollo lato applicazione dovrebbe seguire l’architettura e la direzione a lungo termine dell’applicazione. Le nuove applicazioni usano spesso OpenID Connect per l’accesso e OAuth 2.0 per le API. Le applicazioni aziendali esistenti possono dover rimanere su SAML 2.0 finché non vengono sostituite.

In FoxIDs, l’applicazione è registrata con il protocollo che utilizza. L’identity provider esterno è configurato come authentication method con il protocollo che offre. FoxIDs si trova sul confine di trust:

SAML 2.0 identity provider → FoxIDs → applicazione OpenID Connect

È possibile anche il percorso inverso:

OpenID Connect identity provider → FoxIDs → applicazione SAML 2.0

Questa separazione consente ai team di standardizzare un contratto applicativo senza imporre che tutti gli identity providers esterni cambino contemporaneamente.

Due percorsi di protocol bridging tramite FoxIDs: da SAML 2.0 a OpenID Connect e da OpenID Connect a SAML 2.0.
FoxIDs consente all’applicazione e all’identity provider di utilizzare i protocolli supportati, fungendo da confine di trust comune.

Preserva la semantica dell’identità, non solo i nomi dei claims

SAML assertions e OpenID Connect tokens rappresentano l’identità in modo diverso. Un mapping diretto dei nomi raramente basta in produzione.

Definisci esplicitamente il contratto:

  • Quale identificatore rimane stabile per la stessa persona fra sessioni e identity providers?
  • Quali claims servono per visualizzazione, autorizzazione e audit?
  • Come vengono rappresentati, filtrati e trasformati gruppi e ruoli?
  • Quali issuer e audience considera attendibili l’applicazione?
  • Cosa accade se un provider esterno omette un claim obbligatorio?
  • Le identità di più providers possono essere correlate in sicurezza o devono rimanere separate?

FoxIDs usa JWT claims internamente e può mappare i tipi di claim SAML ai nomi più brevi comuni in OpenID Connect. Questo claim mapping può anche trasformare i valori prima che raggiungano l’applicazione. Mantieni il mapping deliberatamente limitato: emetti ciò che serve all’applicazione invece di copiare ogni attributo in ogni token.

Gli identificatori stabili richiedono attenzione. Indirizzi e-mail e nomi utente possono cambiare e solitamente non sono buone chiavi primarie. Preferisci un identificatore sorgente immutabile insieme a un issuer chiaramente definito o un altro identificatore con ciclo di vita controllato.

Identificatori, claims e contesto di autenticazione SAML 2.0 mappati tramite FoxIDs nei token OpenID Connect.
Il bridge mappa identificatori stabili, i claims necessari e i segnali di assurance invece di copiare ogni attributo dall’identity provider esterno.

Segui un’identità attraverso il bridge

Considera un utente partner che accede tramite un SAML 2.0 identity provider mentre l’applicazione usa OpenID Connect:

  • La SAML assertion fornisce un NameID immutabile, un indirizzo e-mail, l’appartenenza ai gruppi e un authentication context.
  • FoxIDs convalida firma, issuer, audience e validità, quindi mappa l’identificatore sorgente stabile su sub, i gruppi selezionati sui ruoli applicativi e l’authentication context accettato su acr.
  • L’applicazione riceve solo gli OpenID Connect claims concordati e convalida FoxIDs come issuer.

L’applicazione non necessita di logica SAML specifica per il partner. Quando viene aggiunto un altro identity provider partner, i suoi claims e segnali di assurance vengono normalizzati al confine FoxIDs senza modificare il contratto del token dell’applicazione.

Gestisci consapevolmente l’authentication assurance

Un accesso SAML riuscito non comunica automaticamente a un’applicazione OpenID Connect se è stata usata MFA o quali requisiti di assurance sono stati soddisfatti.

Definisci il rapporto fra SAML authentication context, OpenID Connect authentication context e valori acr attesi. Decidi se FoxIDs può accettare l’assurance esterna, deve chiedere all’identity provider esterno un authentication step più forte o deve rifiutare l’accesso quando manca il context necessario.

Lo stesso principio vale al contrario. Un’applicazione SAML 2.0 può aspettarsi un authentication context specifico anche quando l’utente accede tramite OpenID Connect identity provider.

Non dedurre un’authentication forte solo dall’esistenza di una sessione presso l’identity provider esterno. Valuta l’authentication context restituito rispetto alle regole di assurance configurate e prova sia i percorsi accettati sia quelli rifiutati.

Distingui le sessioni di accesso dalle informazioni di logout

OpenID Connect e SAML 2.0 hanno meccanismi differenti per sessione e logout. L’identity provider esterno e l’applicazione mantengono ciascuno la propria sessione di accesso. FoxIDs non mantiene una terza sessione di accesso dell’utente tra i due, ma conserva solo le informazioni di sessione necessarie per coordinare il logout.

Durante l’accesso, la reauthentication e lo step-up, FoxIDs invia una authentication request all’identity provider esterno. FoxIDs non riutilizza le informazioni di logout come sessione di accesso. L’identity provider esterno decide, in base alla propria sessione e ai requisiti della request, se l’utente può proseguire senza interazione o deve autenticarsi nuovamente.

FoxIDs può usare le informazioni di logout conservate per coordinare il logout nelle relazioni interessate. Il single logout end-to-end può funzionare se tutti supportano flussi compatibili e il browser raggiunge ogni endpoint, ma non va dato per scontato. Prova front-channel redirects, sessioni esterne scadute, logout parziale, più applicazioni e logout avviato dal provider.

Allinea la durata dell’applicazione e dei token al comportamento atteso della sessione dell’identity provider esterno. La chiusura della sessione applicativa non termina necessariamente quella esterna. I requisiti di reauthentication e step-up devono essere inviati in una nuova request e verificati tramite l’authentication context restituito.

Pianifica una migrazione graduale da SAML a OpenID Connect

Una migrazione controllata mantiene visibili bridge, contratto e percorso di rollback.

  1. Inventaria le relazioni attuali. Registra applicazioni, identity providers, metadati, certificati, endpoints, claims, identificatori, requisiti MFA, sessioni e responsabili.
  2. Definisci il contratto target. Decidi quali applicazioni useranno OpenID Connect, quali relazioni SAML 2.0 resteranno e quali claims e segnali di assurance attraverseranno il bridge.
  3. Configura entrambe le relazioni di trust. Aggiungi il provider esterno come FoxIDs authentication method e l’applicazione come FoxIDs application registration.
  4. Prova anche gli errori. Includi firme non valide, issuer o audience errati, claims mancanti, assertions scadute, protezione replay, differenze di orario, logout e rotazione dei certificati.
  5. Lavora in un ambiente separato. Convalida senza modificare il traffico di produzione e promuovi poi la configurazione controllata fra gli ambienti.
  6. Sposta prima un gruppo limitato. Usa un’applicazione pilota, un partner o un gruppo di utenti e mantieni il percorso precedente finché il nuovo non è verificato.
  7. Osserva e completa il cut-over. Monitora errori di authentication, differenze nei claims e richieste di supporto prima di rimuovere la vecchia relazione di trust.

I FoxIDs tenants possono contenere ambienti separati di sviluppo, test, migrazione e produzione. Questo supporta validazione parallela e cut-over graduale, ma non sostituisce un piano di rollback né i test applicativi.

Migrazione in sette fasi dall’inventario e dal contratto target alla configurazione del trust, ai test, agli ambienti controllati, al pilot e al cut-over in produzione, con rollback.
Una migrazione graduale convalida le relazioni di trust e il comportamento dell’applicazione prima del passaggio in produzione e mantiene disponibile il rollback finché il nuovo percorso non è stato verificato.

Richiedi prove di produzione prima del cut-over

Il bridge entra nel percorso di authentication e deve essere gestito come confine di sicurezza. Concorda le prove richieste per ogni decisione di produzione invece di considerare un accesso riuscito come accettazione.

Area decisionale Prove richieste prima della produzione
Trust endpoints Responsabili nominati, metadati verificati e restrizioni per issuer, audience, recipient e redirect URI
Credentials Chiavi controllate separate, algoritmi accettati, un test di rotazione dei certificati e un responsabile del rinnovo
Contratto di identità Subject stabile, elenco dei claims consentiti, trasformazioni documentate e comportamento definito quando mancano claims obbligatori
Authentication assurance Contexts esterni accettati, regole per MFA aggiuntiva e percorsi di rifiuto testati
Accesso e logout Inoltro testato delle requests di accesso, reauthentication e step-up, oltre a logout, logout parziale e durate pertinenti dei token e delle sessioni esterne
Errori e operazioni Test di messaggi non validi, scaduti e riprodotti, oltre ad audit logs, avvisi, responsabilità del supporto e una decisione di rollback

Non copiare chiavi private fra sistemi solo per semplificare la migrazione. Assegna credentials controllate a ogni relazione di trust e pianifica la rotazione prima della scadenza dei certificati.

Come FoxIDs supporta il bridge

FoxIDs implementa il protocol bridging tramite il normale modello di applications e authentication methods. Non serve distribuire un bridge service separato. Un’applicazione OpenID Connect può usare authentication methods SAML 2.0, OpenID Connect o WS-Federation, e un’applicazione SAML 2.0 può usare le stesse fonti esterne.

I team mantengono un unico contratto FoxIDs identity provider, mentre identity providers, partner e sistemi legacy si collegano con gli standard supportati. FoxIDs offre inoltre claim mapping, authentication flows configurabili, MFA e ambienti separati di test e produzione.

Consulta la documentazione del protocol bridge per il modello esatto, le authentication methods e le application registrations. Se il lavoro include onboarding, progettazione dei claims, test o migrazione graduale, FoxIDs Identity Integration descrive il supporto all’implementazione offerto dal team che sviluppa la piattaforma.

Conclusione

Un bridge da SAML a OpenID Connect è più utile quando consente ad applicazioni e identity providers di evolvere indipendentemente senza indebolire il contratto di identità.

Tratta il bridge come un confine di trust intenzionale, non come un traduttore di token invisibile. Quando il contratto applicativo, le regole di assurance, il comportamento di accesso e logout, le prove di produzione, le responsabilità e il rollback sono espliciti, FoxIDs fornisce il modello di implementazione basato su standard per introdurre il cambiamento in fasi controllate.