Modello di identità federativa

Delegare l'autenticazione utente a un provider di identità esterno (IdP) per semplificare lo sviluppo, ridurre al minimo le attività amministrative e migliorare l'esperienza utente dell'applicazione.

Contesto e problema

Gli utenti devono in genere lavorare con più applicazioni che le organizzazioni partner forniscono e ospitano. Potrebbe essere necessario usare credenziali di accesso specifiche e diverse per ogni applicazione. Questo requisito può:

Causa un'esperienza utente non contigua. I dipendenti spesso dimenticano più credenziali di accesso.
Esporre vulnerabilità di sicurezza. Quando un dipendente lascia l'azienda, l'organizzazione deve disattivare immediatamente l'account. Le grandi organizzazioni spesso saltano questo passaggio critico.
Gestione degli utenti complessa. Gli amministratori gestiscono le credenziali utente, rilasciano promemoria delle password ed eseguono altre attività amministrative.

Gli utenti preferiscono in genere usare le stesse credenziali di accesso per tutte le applicazioni.

Soluzione

Implementare un meccanismo di autenticazione dell'identità federata. Separare l'autenticazione utente dal codice dell'applicazione e delegare l'autenticazione a un IdP attendibile. Questo processo semplifica lo sviluppo, riduce al minimo gli oneri amministrativi e consente l'autenticazione degli utenti tramite una gamma di provider di identità. L'identità federata separa anche l'autenticazione dall'autorizzazione.

Gli IdP attendibili includono directory aziendali, servizi di federazione locali, servizi di token di sicurezza (STS) e IdP social come Microsoft, Google, Yahoo! o Facebook.

Il diagramma seguente illustra il modello di identità federata per un'applicazione client che accede a un servizio che richiede l'autenticazione. L'IdP opera con un STS per fornire l'autenticazione. L'IdP rilascia token di sicurezza con informazioni relative all'utente autenticato. Queste informazioni, denominate attestazioni, includono l'identità dell'utente e possono includere anche altre attestazioni, ad esempio le appartenenze ai ruoli e diritti di accesso più granulari.

Questo modello è detto anche controllo degli accessi in base alle attestazioni. Le applicazioni e i servizi autorizzano l'accesso a caratteristiche e funzionalità sulla base delle attestazioni. Il servizio che richiede l'autenticazione deve considerare attendibile l'IdP (Identity Provider). L'applicazione client contatta l'IdP per l'autenticazione. Se l'autenticazione ha esito positivo, l'Identity Provider (IdP) restituisce al servizio token di sicurezza (STS) un token che contiene attestazioni che identificano l'utente. L'IdP e lo STS potrebbero far parte dello stesso servizio. STS può trasformare e arricchire i claim in base a regole predefinite prima di restituire il token al client. L'applicazione client passa quindi questo token al servizio come prova dell'identità.

L'autenticazione federata fornisce un metodo basato su standard per stabilire un trust nelle identità tra domini e supporta l'accesso Single Sign-On (SSO). Molte applicazioni, in particolare applicazioni ospitate nel cloud, usano l'autenticazione federata perché supporta l'accesso SSO senza una connessione di rete diretta a un IdP. Questa progettazione aumenta la sicurezza, perché l'utente non deve creare e immettere credenziali di accesso diverse per più applicazioni. Limita inoltre l'esposizione delle credenziali al solo IdP originale. Le applicazioni visualizzano solo le informazioni di identità autenticate nel token.

Le applicazioni e i servizi che usano l'autenticazione federata non devono fornire funzionalità di gestione delle identità. Invece, l'IdP è responsabile della gestione delle identità e delle credenziali. Quando la directory aziendale si fida dell'IdP, non deve gestire l'identità dell'utente. Questo approccio elimina il sovraccarico amministrativo della gestione delle identità utente basata su directory.

Problemi e considerazioni

Quando si decide come implementare questo modello, tenere presente quanto segue:

L'autenticazione può essere un singolo punto di errore. Per mantenere l'affidabilità e la disponibilità delle applicazioni in più aree, è consigliabile distribuire il meccanismo di gestione delle identità nelle stesse aree dell'applicazione.
Per configurare il controllo degli accessi in base al ruolo, usare gli strumenti di autenticazione. Il RBAC consente un controllo granulare sull'accesso alle funzionalità e alle risorse.
A differenza di una directory aziendale, l'autenticazione basata sulle attestazioni che usa i provider di identità di social networking fornisce in genere solo l'indirizzo di posta elettronica dell'utente autenticato e talvolta il nome. Alcuni provider di identità social, come Microsoft, forniscono solo un identificatore univoco. L'applicazione mantiene in genere alcune informazioni sugli utenti registrati in modo che possa corrispondere a queste informazioni all'identificatore nelle attestazioni. Questa attività viene in genere completata durante la registrazione, quando l'utente accede per la prima volta all'applicazione. Le informazioni vengono quindi inserite nel token come nuove attestazioni dopo ogni autenticazione.
Se per lo STS sono configurati più provider di identità (IdP), lo STS deve determinare quale IdP deve autenticare l'utente. Questo processo si chiama home realm discovery. Il Security Token Service (STS) potrebbe determinare automaticamente l'Identity Provider (IdP) in base a informazioni fornite dall'utente, ad esempio un indirizzo e-mail o un nome utente, il sottodominio dell'applicazione, l'intervallo di indirizzi IP dell'utente oppure un cookie archiviato nel browser dell'utente. Ad esempio, se l'utente immette un indirizzo di posta elettronica Microsoft, ad esempio user@live.com, STS reindirizza l'utente alla pagina di accesso dell'account Microsoft. Nelle visite successive, STS può usare un cookie che indica che l'utente ha effettuato in precedenza l'accesso usando un account Microsoft. Se il servizio token di sicurezza non riesce a determinare automaticamente l'area di autenticazione principale, visualizza una pagina di individuazione dell'area di autenticazione principale che elenca gli IDP attendibili. L'utente seleziona quindi un IdP.

Quando usare questo modello

Usare questo modello quando necessario:

SSO nell'organizzazione. In questo scenario è necessario autenticare i dipendenti per le applicazioni aziendali ospitate nel cloud al di fuori del limite di sicurezza aziendale, senza un accesso ogni volta che visitano un'applicazione. L'esperienza utente corrisponde alle applicazioni locali. Gli utenti eseguono l'autenticazione quando accedono alla rete aziendale e quindi possono accedere alle applicazioni pertinenti senza un altro accesso.
Identità federata con più partner. In questo scenario è necessario autenticare i dipendenti aziendali e i partner aziendali che non hanno account nella directory aziendale. Questa procedura è comune nelle applicazioni business-to-business, nelle applicazioni che si integrano con i servizi partner e nelle aziende che usano sistemi IT diversi o risorse unite o condivise.
Identità federata nelle applicazioni SaaS (Software as a Service). In questo scenario, i fornitori di software indipendenti forniscono un servizio pronto per l'uso per più client o tenant. I tenant eseguono l'autenticazione usando un IdP appropriato. Ad esempio, gli utenti aziendali usano le proprie credenziali aziendali, mentre i consumer e i client tenant usano le credenziali di identità di social networking.
Identità federata per l'accesso ai carichi di lavoro. In questo scenario, le applicazioni tenant, i flussi di lavoro di automazione o l'integrazione continua e i sistemi di recapito continuo devono chiamare le API senza un utente presente. I tenant eseguono l'autenticazione tramite i propri provider di identità usando le identità del carico di lavoro. L'applicazione autorizza l'accesso mediante la convalida dei claim limitata al tenant.

Questo modello potrebbe non essere adatto quando si dispone di:

Un IdP. In questo scenario gli utenti dell'applicazione eseguono l'autenticazione usando un IdP e non devono eseguire l'autenticazione usando un altro IdP. Questa situazione è tipica nelle applicazioni che usano una directory aziendale per l'autenticazione, tramite una VPN o una connessione di rete virtuale tra l'applicazione e una directory locale.
Meccanismi di autenticazione incompatibili. In questo scenario, l'applicazione usa un meccanismo di autenticazione diverso, ad esempio usando archivi utente personalizzati o non può gestire gli standard di negoziazione della tecnologia basata sulle attestazioni. Può essere complesso e costoso adattare l'autenticazione basata sulle attestazioni e il controllo di accesso in un'applicazione esistente.

Progettazione del carico di lavoro

Valutare come usare il modello di identità federata nella progettazione di un carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. La tabella seguente fornisce indicazioni su come questo modello supporta gli obiettivi di ogni pilastro.

Pilastro	Come questo modello supporta gli obiettivi di pilastro
decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resiliente a un malfunzionamento e assicurano che ripristini a uno stato completamente funzionante dopo che si verifica un guasto.	Questo modello delega la gestione degli utenti e l'autenticazione all'IdP, che in genere ha un obiettivo di livello di servizio elevato. Durante il ripristino di emergenza del carico di lavoro, il piano di ripristino del carico di lavoro non deve gestire i componenti di autenticazione. - Flussi critici RE:02 - RE:09 DR
Le decisioni di progettazione della sicurezza consentono di garantire la riservatezza, l'integrità e la disponibilità dei dati e dei sistemi del carico di lavoro.	Questo modello offre funzionalità avanzate di rilevamento e prevenzione delle minacce basate sull'identità senza che sia necessario implementarle nel carico di lavoro. Gli IDP esterni usano anche protocolli di autenticazione interoperatori moderni. - SE:02 Ciclo di vita di sviluppo protetto - SE:10 Monitoraggio e rilevamento delle minacce
l'efficienza delle prestazioni consente al carico di lavoro soddisfare in modo efficiente le richieste tramite ottimizzazioni di ridimensionamento, dati e codice.	Questo modello consente di dedicare risorse dell'applicazione ad altre priorità. - PE:03 Selezione dei servizi

Se questo modello introduce compromessi all'interno di un pilastro, considerarli contro gli obiettivi degli altri pilastri.

Example

Un'organizzazione ospita un'applicazione multicomponente basata sul cloud che include un front-end Web e un'API back-end. L'applicazione delega l'autenticazione a un Provider di identità centralizzato usando Microsoft Entra ID anziché implementare la logica di autenticazione in ogni componente.

Scaricare un file di Visio di questa architettura.

Il flusso di lavoro seguente corrisponde al diagramma precedente.

L'utente accede all'app Web.
L'app Web reindirizza l'utente a Microsoft Entra ID per l'autenticazione.
Dopo l'autenticazione, Microsoft Entra ID reindirizza l'utente all'app Web con un codice di autorizzazione.
L'app Web scambia il codice di autorizzazione per i token e invia una richiesta POST all'endpoint del token.
Microsoft Entra ID rilascia un token che contiene attestazioni sull'utente.
L'app Web usa questo token per chiamare un'API back-end.
L'app Web e l'API back-end convalidano il token e applicano le regole di autorizzazione in base alle attestazioni.
L'API restituisce la risposta all'app Web.

Caratteristiche chiave:

Autenticazione centralizzata. I componenti si basano su Microsoft Entra ID per autenticare gli utenti, eliminando la necessità di una logica di autenticazione personalizzata nell'applicazione.
Autorizzazione decentralizzata. I componenti dell'applicazione applicano in modo indipendente le decisioni di autorizzazione in base alle attestazioni.
Controllo degli accessi in base alle attestazioni. L'accesso alle funzionalità viene determinato tramite attestazioni, ad esempio ruoli o ambiti.
Protocolli basati su standard. I componenti usano OAuth 2.0 e OpenID Connect per l'autenticazione.
Applicazione facoltativa dell'MFA. Se il profilo di rischio richiede una maggiore garanzia di accesso, è possibile applicare l'autenticazione a più fattori usando i criteri di accesso condizionale in Microsoft Entra ID.
Estendibilità facoltativa tramite la federazione. Microsoft Entra ID può essere configurato per considerare attendibile un tenant partner di Microsoft Entra tramite le impostazioni di accesso tra tenant. Gli utenti partner possono quindi accedere all'applicazione senza modifiche ai componenti dell'applicazione.

Passaggi successivi

Commenti e suggerimenti

Questa pagina è stata utile?

Last updated on 2026-07-02