È possibile delegare l'autenticazione a un provider di identità esterno. Questo può semplificare lo sviluppo, ridurre al minimo i requisiti per l'amministrazione utenti e migliorare l'esperienza utente dell'applicazione.
Contesto e problema
Gli utenti di solito usano più applicazioni messe a disposizione e ospitate da diverse organizzazioni con cui hanno relazioni commerciali. Ogni organizzazione potrebbe richiedere l'uso di credenziali specifiche (e diverse). Ciò potrebbe causare quanto segue:
Un'esperienza utente frammentaria. Gli utenti dimenticano spesso le credenziali di accesso quando ne usano molte.
Esposizione di vulnerabilità della sicurezza. Quando un utente lascia l'azienda, il suo account deve essere immediatamente sottoposto a deprovisioning. È facile trascurare questa esigenza nelle aziende di grandi dimensioni.
Gestione complicata degli utenti. Gli amministratori devono gestire le credenziali per tutti gli utenti ed eseguire attività aggiuntive, ad esempio inviare promemoria per le password.
Gli utenti in genere preferiscono usare le stesse credenziali per tutte le applicazioni.
Soluzione
Implementare un meccanismo di autenticazione in grado di usare l'identità federativa. Separare l'autenticazione utente dal codice dell'applicazione e delegare l'autenticazione a un provider di identità attendibile. In questo modo si semplifica lo sviluppo e si consente agli utenti di eseguire l'autenticazione usando un'ampia gamma di provider di identità (IdP), riducendo al minimo il carico amministrativo. Si consente inoltre di separare chiaramente l'autenticazione dall'autorizzazione.
I provider di identità attendibili includono le directory aziendali, i servizi di federazione locali, altri servizi token di sicurezza (STS) di partner commerciali e i provider di identità social in grado di autenticare gli utenti che hanno, ad esempio, un account Microsoft, Google, Yahoo! o Facebook.
Nella figura viene illustrato il modello di identità federativa quando un'applicazione client deve accedere a un servizio che richiede l'autenticazione. L'autenticazione viene eseguita da un IdP che interagisce con un servizio token di sicurezza. L'IdP rilascia token di sicurezza con informazioni relative all'utente autenticato. Queste informazioni, dette attestazioni, includono l'identità dell'utente e possono includere anche altre informazioni, ad esempio l'appartenenza ai ruoli e diritti di accesso più granulari.
Questo modello viene spesso definito controllo di accesso basato sulle attestazioni. Le applicazioni e i servizi autorizzano l'accesso alle funzionalità basate sulle attestazioni contenute nel token. Il servizio che richiede l'autenticazione deve considerare attendibile il provider di identità. L'applicazione client contatta il provider di identità che esegue l'autenticazione. Se l'autenticazione ha esito positivo, il provider di identità restituisce un token contenente le attestazioni che identificano l'utente per il servizio STS. Si noti che il provider di identità e il servizio token di sicurezza possono essere lo stesso servizio. Il servizio STS può trasformare e ottimizzare le attestazioni nel token in base a regole predefinite, prima di restituirlo al client. L'applicazione client può quindi passare questo token al servizio come prova dell'identità.
Potrebbero essere presenti servizi token di sicurezza aggiuntivi nella catena di attendibilità. Ad esempio, nello scenario descritto in seguito, un servizio token di sicurezza locale ritiene attendibile un altro servizio token di sicurezza che è responsabile dell'accesso a un provider di identità per autenticare l'utente. Questo approccio è comune in scenari aziendali in cui sono presenti un servizio token di sicurezza e una directory locali.
L'autenticazione federata offre una soluzione basata su standard per il problema dell'attendibilità delle identità tra domini diversi ed è in grado di supportare l'accesso Single Sign-On. Questo tipo di autenticazione sta diventando più comune in tutti i tipi di applicazioni, in particolare le applicazioni ospitate nel cloud, perché supporta l'accesso Single Sign-On senza richiedere una connessione di rete diretta ai provider di identità. L'utente non deve immettere le credenziali per ogni applicazione. Ciò aumenta la sicurezza perché impedisce la creazione di credenziali necessarie per accedere a molte applicazioni diverse e nasconde anche le credenziali dell'utente da tutto il provider di identità originale. Le applicazioni vedono solo le informazioni dell'identità autenticata contenute all'interno del token.
Il vantaggio principale offerto dall'identità federativa è il fatto che la gestione delle identità e delle credenziali è responsabilità del provider di identità. L'applicazione o il servizio non richiede l'uso di funzionalità di gestione di identità. Inoltre, negli scenari aziendali, la directory aziendale non richiede informazioni sull'utente se considera attendibile il provider di identità. In questo modo si elimina tutto il carico amministrativo dovuto alla gestione delle identità degli utenti nella directory.
Considerazioni e problemi
Quando si progettano applicazioni che implementano l'autenticazione federata, tenere presente quanto segue:
L'autenticazione può essere un singolo punto di errore. Se si distribuisce l'applicazione a più data center, considerare la possibilità di distribuire il meccanismo di gestione delle identità agli stessi data center per mantenere l'affidabilità e la disponibilità dell'applicazione.
Gli strumenti di autenticazione consentono di configurare il controllo di accesso in base alle attestazioni di ruolo contenute nel token di autenticazione. Ciò è noto anche come controllo di accesso basato sui ruoli (RBAC) e può consentire un livello più granulare di controllo sull'accesso a funzionalità e risorse.
A differenza di una directory aziendale, l'autenticazione basata sulle attestazioni che usa i provider di identità social generalmente non offre informazioni sull'utente autenticato a parte un indirizzo di posta elettronica e forse un nome. Alcuni provider di identità social, ad esempio un account Microsoft, usano solo un identificatore univoco. In genere, l'applicazione deve gestire alcune informazioni sugli utenti registrati ed essere in grado di associare queste informazioni all'identificatore contenuto nelle attestazioni nel token. Ciò avviene di solito durante la registrazione quando l'utente accede per la prima volta all'applicazione e in seguito le informazioni vengono inserite nel token come attestazioni aggiuntive dopo ogni autenticazione.
Se sono configurati più provider di identità per il servizio token di sicurezza, il servizio token di sicurezza deve determinare il provider di identità a cui l'utente deve essere reindirizzato per l'autenticazione. Questo processo è detto individuazione dell'area di autenticazione. Il servizio token di sicurezza potrebbe essere in grado di eseguire questa operazione automaticamente in base a un indirizzo di posta elettronica o a un nome utente fornito dall'utente, a un sottodominio dell'applicazione a cui l'utente accede, all'ambito dell'indirizzo IP dell'utente o al contenuto di un cookie archiviato nel browser dell'utente. Ad esempio, se l'utente ha immesso un indirizzo di posta elettronica nel dominio Microsoft, ad esempio user@live.com, il servizio token di sicurezza reindirizzerà l'utente alla pagina di accesso dell'account Microsoft. Nelle visite successive, il servizio token di sicurezza può usare un cookie per indicare che l'ultimo accesso è stato effettuato con un account Microsoft. Se l'individuazione automatica non è in grado di determinare l'area di autenticazione principale, il servizio token di sicurezza visualizza una pagina di individuazione dell'area di autenticazione in cui sono elencati i provider di identità attendibili e l'utente deve selezionare quello che vuole utilizzare.
Quando usare questo modello
Questo modello è utile per scenari come:
Single Sign-On nell'azienda. In questo scenario i dipendenti vengono autenticati per le applicazioni aziendali ospitate nel cloud all'esterno dei limiti di protezione aziendale, in modo che non siano obbligati a effettuare l'accesso ogni volta che visitano un'applicazione. L'esperienza utente è identica a quella in cui si usano le applicazioni locali per cui si è autenticati quando si accede a una rete aziendale e da questo momento i dipendenti hanno accesso a tutte le applicazioni pertinenti senza dover eseguire nuovamente l'accesso.
Identità federativa con più partner. In questo scenario è necessario autenticare sia i dipendenti aziendali che i partner aziendali che non hanno un account nella directory aziendale. Ciò è comune nelle applicazioni business-to-business, applicazioni integrate con servizi di terze parti in cui le aziende con sistemi IT diversi hanno risorse unite o condivise.
Identità federativa nelle applicazioni SaaS. In questo scenario i fornitori di software indipendenti offrono un servizio pronto per l'uso per più client o tenant. Ogni tenant viene autenticato usando un provider di identità appropriato. Ad esempio, gli utenti aziendali useranno le proprie credenziali aziendali, mentre i consumer e i client del tenant useranno le credenziali di identità social.
Questo modello può non essere utile nelle situazioni seguenti:
Tutti gli utenti dell'applicazione possono essere autenticati da un solo provider di identità e non è obbligatorio eseguire l'autenticazione usando altri provider di identità. Questo è tipico nelle applicazioni aziendali che usano una directory aziendale (accessibile nell'applicazione) per l'autenticazione, usando una VPN o, in uno scenario ospitato nel cloud, una connessione di rete virtuale tra la directory locale e l'applicazione.
L'applicazione originariamente è stata creata usando un diverso meccanismo di autenticazione, probabilmente con archivi utente personalizzati, oppure non è in grado di gestire gli standard di negoziazione usati dalle tecnologie basate su attestazioni. L'adeguamento del controllo di accesso e dell'autenticazione basata su attestazioni nelle applicazioni esistenti può essere complesso ed economicamente non conveniente.
Progettazione del carico di lavoro
Un architetto deve valutare il modo in cui il modello di identità federata può essere usato nella progettazione del carico di lavoro per soddisfare gli obiettivi e i principi trattati nei pilastri di Azure Well-Architected Framework. Ad esempio:
| Concetto fondamentale | Come questo modello supporta gli obiettivi di pilastro |
|---|---|
| Le decisioni di progettazione dell'affidabilità consentono al carico di lavoro di diventare resilienti a malfunzionamenti e di assicurarsi che venga ripristinato in uno stato completamente funzionante dopo che si verifica un errore. | L'offload della gestione degli utenti e dell'autenticazione sposta l'affidabilità per tali componenti nel provider di identità, che in genere ha un SLO elevato. Inoltre, durante il ripristino di emergenza del carico di lavoro, è probabile che i componenti di autenticazione non debbano essere risolti come parte del piano di ripristino del carico di lavoro. - Flussi critici RE:02 - RE:09 Ripristino di emergenza |
| 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. | Esternalizzando la gestione e l'autenticazione degli utenti, è possibile ottenere funzionalità avanzate per il rilevamento e la prevenzione delle minacce basate sull'identità senza dover implementare queste funzionalità nel carico di lavoro. I provider di identità esterni usano protocolli di autenticazione interoperatori moderni. - edizione Standard:02 Ciclo di vita di sviluppo protetto - edizione Standard:10 Monitoraggio e rilevamento delle minacce |
| L'efficienza delle prestazioni consente al carico di lavoro di soddisfare in modo efficiente le richieste tramite ottimizzazioni in termini di scalabilità, dati, codice. | Quando si esegue l'offload della gestione e dell'autenticazione degli utenti, è possibile dedicare le risorse dell'applicazione ad altre priorità. - PE:03 Selezione dei servizi |
Come per qualsiasi decisione di progettazione, prendere in considerazione eventuali compromessi rispetto agli obiettivi degli altri pilastri che potrebbero essere introdotti con questo modello.
Esempio
Un'organizzazione ospita un'applicazione SaaS (Software as a Service) multi-tenant in Microsoft Azure. L'applicazione include un sito Web che i tenant possono usare per gestire l'applicazione per i propri utenti. L'applicazione consente ai tenant di accedere al sito Web usando un'identità federata generata da Active Directory Federation Services (AD FS) quando un utente viene autenticato da Active Directory.
La figura mostra come i tenant eseguono l'autenticazione con il proprio provider di identità (passaggio 1), in questo caso AD FS. Dopo l'autenticazione di un tenant, AD FS rilascia un token. Il browser client inoltra questo token al provider federativo dell'applicazione SaaS, che considera attendibili i token emessi da AD FS del tenant, per ottenere un token valido per il provider federativo SaaS (passaggio 2). Se necessario, il provider federativo SaaS esegue una trasformazione delle attestazioni contenute nel token in attestazioni che l'applicazione è in grado di riconoscere (passaggio 3) prima di restituire il nuovo token al browser client. L'applicazione considera attendibili i token rilasciati dal provider federativo SaaS e usa le attestazioni nel token per applicare le regole di autorizzazione (passaggio 4).
I tenant non dovranno ricordare credenziali separate per accedere all'applicazione e un amministratore della società del tenant può configurare nel proprio AD FS l'elenco di utenti che possono accedere all'applicazione.
Passaggi successivi
- Microsoft Entra ID
- Active Directory Domain Services
- Active Directory Federation Services
- Applicazioni multi-tenant in Azure