L’identità federata (o federated identity) è un modello che permette agli utenti di usare una singola identità digitale per accedere a risorse e servizi distribuiti su domini, reti o organizzazioni diverse. In pratica, invece di dover creare (e ricordare) un account separato per ogni servizio, l’utente possiede un’identità gestita da un provider — l’Identity Provider (IdP) — che viene riconosciuta anche da altri enti (“service provider”, SP) con i quali l’IdP ha stabilito un patto di fiducia.

In questo modo, chi fornisce il servizio (SP) non deve gestire direttamente la verifica delle credenziali dell’utente (password, dati biometrici, etc.), ma si affida all’IdP che già conosce e ha autenticato quell’utente. Questo approccio riduce la duplicazione dei dati, facilita la gestione della sicurezza e può migliorare l’esperienza utente.

Come funziona la gestione dell’identità federata (What is federated identity management)?

La gestione federata delle identità (Federated Identity Management, FIM) è l’insieme di processi, policy, tecnologie e protocolli che rendono possibile l’identità federata.

Ecco le componenti principali:

• Identity Provider (IdP): chi autentica l’utente e tiene traccia della sua identità (username, certificati, attributi vari).
• Service Provider (SP): l’applicazione o servizio che l’utente vuole usare, ma che non gestisce le credenziali internamente; si fida dell’IdP.
• Protocolli di federazione (Identity federation protocols): regole e standard che permettono al SP e all’IdP di comunicare in modo sicuro per scambiarsi le informazioni necessarie all’autenticazione e autorizzazione.

Alcuni dei più noti identity federation protocols sono:

• SAML (Security Assertion Markup Language): molto usato in ambito enterprise, in scenari tra organizzazioni;
• OAuth: permette in genere deleghe di accesso; spesso usato insieme a OpenID Connect;
• OpenID Connect (OIDC): costruito sopra OAuth, con focus sull’autenticazione e non solo sull’autorizzazione.

Il processo tipico è:

1. L’utente si autentica presso l’IdP (fornendo credenziali, eventualmente MFA, etc.).
2. Quando vuole usare un servizio (SP) federato, il SP invia una richiesta di autenticazione all’IdP.
3. L’IdP verifica l’identità dell’utente e restituisce al SP una risposta (assertion) che attesta che quell’utente è chi afferma di essere.
4. Il SP concede l’accesso all’utente basandosi su quell’assertion e su eventuali attributi (come ruoli, permessi, etc.).

Federated identity vs SSO (Federated identity vs Single Sign-On)

Spesso si rischia di confondere federated identity con SSO (Single Sign-On); sono concetti affini ma con differenze precise.

SSO è una tecnologia o servizio che permette a un utente di accedere a più applicazioni o sistemi all’interno della stessa organizzazione o dominio, utilizzando un solo login. Una volta autenticato, l’utente non deve ripetere l’accesso per ogni applicazione correlata.

Federated identity management, invece, va oltre: consente l’accesso non solo alle risorse di una singola organizzazione, ma anche a quelle di partner esterni, domini diversi, etc., grazie a fiducia reciproca e protocolli condivisi.

In sintesi, SSO può essere visto come un sottoinsieme o un caso speciale di federated identity — quando l’ambito è ristretto a una singola organizzazione. Ma federated identity può abilitare scenari molto più ampi e complessi, inter-organizzativi.

Federated authentication

L’autenticazione federata è il meccanismo che permette a un IdP esterno di verificare l’identità di un utente per conto del SP. È la parte essenziale che permette all’identità federata di funzionare: l’utente si autentica una sola volta con l’IdP, e quell’autenticazione è riconosciuta da vari SP.

Alcuni aspetti importanti della federated authentication:

• può includere misure di sicurezza aggiuntive come l’autenticazione a più fattori (MFA);
• deve gestire il trasferimento sicuro delle assertions (prove che l’autenticazione è avvenuta) dal provider all’applicazione;
• deve rispettare il principio di divulgazione minima (cioè condividere solo le informazioni strettamente necessarie).

Esempio pratico (Federated identity management example)

Per capire meglio cosa significa concretamente gestione federata, ecco un esempio: immagina che un’università (Università A) desideri che i suoi studenti abbiano accesso a risorse online fornite da un consorzio di biblioteche digitali (Biblioteca B, Biblioteca C) e a una piattaforma di conferenze che è esterna all’università.

L’università A funge da Identity Provider (IdP). Gli studenti hanno le loro credenziali (username + password, oppure password + MFA).

Le biblioteche digitali e la piattaforma di conferenze sono i Service Provider (SP).

Quando uno studente vuole accedere alla piattaforma di conferenze, non deve creare un nuovo account. L’applicazione di conferenze manda una richiesta di autenticazione all’IdP dell’università A.

L’IdP verifica le credenziali, magari chiede MFA, poi invia un’assertion che dice “questo utente è lo stesso studente X, con determinati attributi (es. matricola, corso di studi)”.

La piattaforma lo accetta e concede l’accesso.

Questo è un classico federated identity management example. Permette all’università di controllare centralmente l’accesso e all’utente di muoversi più liberamente, senza troppe password da ricordare.

Federated identity Microsoft

Nel mondo Microsoft, l’identità federata è un concetto ben supportato e diffuso. Alcune caratteristiche rilevanti:

• Microsoft Azure Active Directory (Azure AD) può agire da Identity Provider federato, consentendo l’accesso a risorse Microsoft (Office 365, Dynamics, etc.) e risorse esterne che supportano protocolli come SAML, OAuth/OIDC.
• Microsoft supporta la federazione degli account con provider esterni: ad esempio, un’organizzazione può federare il proprio dominio locale (Active Directory on‑premises) con Azure AD, in modo che gli utenti possano usare le credenziali del dominio locale per accedere anche a risorse cloud Microsoft o applicazioni esterne compatibili.
• Con Microsoft, lo SSO federation è spesso realizzato tramite Azure AD, che fa da hub federato, integrando identità che possiedono attributi consolidati (ruoli, gruppi, politiche di accesso condizionato).

Quindi “federated identity Microsoft” è un esempio concreto in cui un enorme ecosistema aziendale/cloud si basa su federazione per facilitare sicurezza e accesso senza soluzione di continuità.

Vantaggi dell’identità federata

L’identità federata porta con sé vari benefici:

1. Maggiore sicurezza: concentrando il processo di autenticazione in pochi provider affidabili si riduce il rischio che ogni servizio individuale faccia errori di gestione delle password. Si possono applicare politiche coerenti (password policy, MFA, monitoraggio anomalie).
2. Esperienza utente migliorata: meno password, meno login ripetuti; meno frustrazione per l’utente finale che passa da un servizio a un altro.
3. Riduzione dei costi operativi: le organizzazioni non devono replicare sistemi di autenticazione e gestione account per ogni SP; meno gestione di help desk per reset password, meno duplicazioni.
4. Scalabilità & interoperabilità: con federazioni si possono aggiungere nuovi partner o servizi relativamente facilmente se tutti adottano protocolli compatibili.
5. Controllo e governance centralizzata: l’organizzazione che funge da IdP può definire politiche di sicurezza comuni, monitoraggio centralizzato, revoca dell’accesso, etc.

Limiti

Naturalmente, l’identità federata non è priva di difficoltà:

• serve fiducia tra le organizzazioni: l’IdP e gli SP devono riconoscersi reciprocamente, accettare standard comuni e policy condivise;
• la gestione degli attributi: che cosa viene condiviso? Quanto informazione è necessaria? Si devono bilanciare privacy e funzionalità;
• sicurezza: se l’IdP viene compromesso, l’attaccante potenzialmente ottiene accesso a molti servizi. Serve protezione forte, auditing, backup, recovery;
• interoperabilità: differenze tra protocolli, versioni, implementazioni, certificati, etc., possono causare problemi pratici.

Federated Identity: esempi del mondo reale

Oltre all’esempio universitario di prima, eccoti altri contesti che illustrano come possa essere applicata:

• aziende che collaborano: due società partner hanno sistemi diversi, ma decidono che i dipendenti di una possano accedere direttamente alle applicazioni dell’altra usando la federazione. Esempio: una società di consulenza che accede al portale clienti di un’altra azienda partner senza conti separati;
• login social: molti siti permettono di registrarsi / accedere tramite Google, Facebook, Apple, etc. Questo è federated authentication: l’identità è verificata dal provider esterno (es. Google) e il sito riceve conferma che quell’utente è autenticato (insieme ad alcuni attributi come l’email).

Conclusioni

In sintesi, l’identità federata è un approccio potente per semplificare l’esperienza dell’utente nell’accedere a più sistemi, migliorare la sicurezza complessiva e ridurre la gestione delle credenziali duplicate. Richiede però cura nella definizione delle policy, nella scelta dei protocolli, nella gestione della fiducia fra le parti coinvolte.

Credits: peshkov /Depositphotos.com