Stai collegando l’accesso aziendale a una nuova app e il modulo chiede un “SSO ID”: spesso è l’identificativo con cui il servizio riconosce l’account dopo l’autenticazione, ma il nome del campo può indicare anche l’identità dell’applicazione. La differenza dipende dal punto della configurazione, e confonderli può bloccare l’accesso.
L’ID giusto collega la persona all’app senza confonderlo con l’app stessa
- SSO ID utente: identifica l’account che entra nel servizio.
- Entity ID: identifica una parte della configurazione SAML, spesso l’app o il provider.
- Email: è pratica, ma può cambiare e creare problemi di associazione dell’account.
- Controllo utile: verifica quale valore invia l’identity provider e quale si aspetta l’app.
SSO ID può indicare la persona o l’applicazione
Nel pannello dell’app trovi un campo chiamato “SSO identifier”; nel portale del provider compare invece “Identifier”. Le etichette si assomigliano, ma i valori possono avere funzioni diverse: il primo spesso serve a trovare l’account utente, il secondo può identificare l’applicazione nella relazione SAML.
Con SAML, il NameID è un identificativo dell’utente trasmesso nell’asserzione. L’Entity ID identifica invece un’entità della federazione, per esempio un identity provider o un service provider. In OpenID Connect, il claim sub identifica l’utente per il client che riceve il token. Perciò un valore che sembra un indirizzo web può essere un identificativo dell’app, non il login di una persona.
Il controllo iniziale è semplice: chiedi al fornitore dell’app quale attributo usa per associare l’account e confrontalo con il valore configurato nel provider. Non inserire automaticamente l’email nel campo “Identifier”: prima verifica a quale delle due identità si riferisce.
L’email è comoda, ma può diventare una chiave fragile
Quando una persona cambia cognome, reparto o dominio aziendale, l’indirizzo può cambiare mentre l’account applicativo deve restare lo stesso. Se l’app usa l’email come chiave di associazione, può non trovare il profilo precedente o creare un secondo account. La comodità iniziale può trasformarsi in lavoro manuale durante una riorganizzazione.
Per OpenID Connect Core 1.0, il claim sub è un identificativo univoco nell’ambito dell’emittente e non deve essere riassegnato. La specifica prevede anche identificativi “pairwise”, diversi per ciascun client: due app possono quindi ricevere valori differenti per la stessa persona. Questo aiuta a limitare il collegamento delle attività tra servizi, ma richiede che ogni app mantenga la propria associazione corretta.
Come criterio operativo, se l’account deve sopravvivere ai cambi di email, scegli un identificativo stabile e concordato tra provider e app. Se invece vuoi evitare che servizi distinti correlino la stessa persona, valuta un identificativo pairwise. In entrambi i casi, documenta come gestire cambi di identità e disattivazioni, prima di attivare l’accesso per tutti.
Un accesso riuscito dipende dal valore che l’app si aspetta
Una persona può autenticarsi correttamente e poi essere respinta dall’app: significa che il provider ha verificato l’identità, ma il servizio potrebbe non aver associato l’identificativo a un account o ai permessi corretti. Autenticazione e autorizzazione sono controlli distinti: entrare non equivale ad avere accesso a ogni funzione.
| Situazione | Possibile causa | Cosa controllare |
|---|---|---|
| Compare l’errore AADSTS70001 | L’Issuer della richiesta SAML non coincide con l’Identifier registrato per l’app | Confronta i due valori, inclusa l’eventuale barra finale, nella configurazione SAML. |
| La verifica del provider riesce, ma l’app non trova l’account | Il NameID o l’attributo inviato non corrisponde alla chiave salvata nell’app | Confronta l’identificativo ricevuto con quello dell’account esistente. |
| Il problema appare dopo un cambio di email | L’app potrebbe usare l’indirizzo come chiave oppure aver creato un profilo duplicato | Verifica la mappatura e aggiorna l’associazione senza eliminare il profilo corretto. |
| La stessa persona riceve ID diversi in app diverse | OpenID Connect può usare identificativi pairwise per client | Controlla l’associazione separatamente in ciascun servizio. |
Per l’errore AADSTS70001, Microsoft Learn indica proprio una mancata corrispondenza fra Issuer e Identifier; il controllo va eseguito nella configurazione dell’app aziendale e deve includere eventuali differenze nel valore completo. Evita di inviare asserzioni o token in ticket pubblici: possono contenere dati personali e informazioni utili a chi tenta un accesso improprio.
La revoca dell’account va progettata insieme al login
Un accesso centralizzato semplifica la gestione quotidiana, ma la chiusura dell’account nel provider non sempre chiude all’istante ogni sessione già aperta nell’app. Il punto delicato è il tempo che intercorre tra la disattivazione e la fine delle sessioni attive.
Per ogni servizio, definisci chi disabilita l’account, come vengono aggiornati i gruppi e come si revocano le sessioni applicative. Se l’app supporta il provisioning automatico, coordina anche la rimozione dell’utente: SSO gestisce l’autenticazione, mentre il provisioning sincronizza account e attributi. Sono processi collegati, ma uno non sostituisce l’altro.
Una verifica concreta consiste nel provare un’uscita simulata: disattiva un account di test nel provider, controlla se può ancora usare una sessione già aperta e documenta il risultato. Se l’accesso persiste, aggiungi la revoca delle sessioni o una procedura di disattivazione nell’app, invece di affidarti al solo logout dal provider.
Un identificativo stabile riduce gli interventi ripetuti
Quando ogni app interpreta l’identità a modo suo, il reparto IT finisce per correggere accessi duplicati e attribuzioni errate. A mio avviso, per un’azienda che vuole snellire i processi digitali, la scelta più solida è concordare un identificativo stabile per ogni servizio e mantenere l’email come attributo aggiornabile, se l’app lo consente.
Prima di estendere l’SSO a tutta l’organizzazione, verifica tre passaggi: il provider autentica la persona, l’app riconosce l’identificativo ricevuto e i permessi corrispondono al ruolo assegnato. Un solo accesso è davvero più semplice quando anche il ciclo di vita dell’account è sotto controllo.