Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Nella soluzione 3 il provider di federazione è il provider di identità primario (IdP). In questo esempio Shibboleth è il provider federativo per l'integrazione di app federate multilaterali, app del Servizio di autenticazione centrale locale e qualsiasi directory LDAP (Lightweight Directory Access Protocol).
In questo scenario Shibboleth è il provider di identità primario. La partecipazione alle federazioni multilaterali (ad esempio, con InCommon) viene eseguita tramite Shibboleth, che supporta in modo nativo questa integrazione. Le app CAS locali e la directory LDAP sono integrate anche con Shibboleth.
Le app per studenti, le app per istituti di istruzione e Microsoft 365 Apps sono integrate con Microsoft Entra ID. Qualsiasi istanza locale di Active Directory viene sincronizzata con Microsoft Entra ID. Active Directory Federation Services (AD FS) offre l'integrazione con l'autenticazione a più fattori di terze parti. AD FS esegue la conversione del protocollo e abilita alcune funzionalità di Microsoft Entra, ad esempio l'aggiunta a Microsoft Entra per la gestione dei dispositivi, Windows Autopilot e le funzionalità senza password.
Vantaggi
Ecco alcuni dei vantaggi dell'uso di questa soluzione:
Autenticazione personalizzata: È possibile personalizzare l'esperienza per le app federate multilaterali tramite Shibboleth.
Facilità di esecuzione: La soluzione è semplice da implementare a breve termine per le istituzioni che già usano Shibboleth come idP principale. È necessario eseguire la migrazione di app per studenti e docenti a Microsoft Entra ID e aggiungere un'istanza di AD FS.
Interruzione minima: La soluzione consente l'autenticazione a più fattori di terze parti. È possibile mantenere le soluzioni di autenticazione a più fattori esistenti, ad esempio Duo, fino a quando non si è pronti per un aggiornamento.
Considerazioni e compromessi
Ecco alcuni dei compromessi dell'uso di questa soluzione:
Maggiore complessità e rischio per la sicurezza: Un footprint locale potrebbe comportare una maggiore complessità per l'ambiente e rischi di sicurezza aggiuntivi rispetto a un servizio gestito. Un aumento del sovraccarico e dei costi potrebbe anche essere associato alla gestione dei componenti locali.
Esperienza di autenticazione non ottimale: Per le app di federazione e cas multilaterali, non esiste alcun meccanismo di autenticazione basato sul cloud e potrebbero essere presenti più reindirizzamenti.
Nessun supporto per l'autenticazione a più fattori Di Microsoft Entra: Questa soluzione non abilita il supporto dell'autenticazione a più fattori Di Microsoft Entra per le app di federazione multilaterale o cas. Potresti perdere potenziali risparmi sui costi.
Nessun supporto granulare per l'accesso condizionale: La mancanza di supporto granulare per l'accesso condizionale limita la possibilità di prendere decisioni granulari.
Allocazione significativa del personale in corso: Il personale IT deve gestire l'infrastruttura e il software per la soluzione di autenticazione. Qualsiasi attrito del personale potrebbe introdurre rischi.
Risorse per la migrazione
Le risorse seguenti possono essere utili per la migrazione a questa architettura della soluzione.
| Risorsa di migrazione | Descrizione |
|---|---|
| Risorse per la migrazione di applicazioni a Microsoft Entra ID | Elenco di risorse che consentono di eseguire la migrazione dell'accesso e dell'autenticazione delle applicazioni a Microsoft Entra ID |
Passaggi successivi
Vedere questi articoli correlati sulla federazione multilaterale:
Introduzione alla federazione multilaterale
Progettazione di base di federazione multilaterale
Soluzione federativa multilaterale 1: Microsoft Entra ID con Cirrus Bridge