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 2, l'ID Microsoft Entra funge da provider di identità primario (IdP). Il provider federativo funge da proxy SAML (Security Assertion Markup Language) alle app del Servizio di autenticazione centrale (CAS) e alle app federate multilaterali. In questo esempio Shibboleth funge da proxy SAML per fornire un collegamento di riferimento.
Poiché Microsoft Entra ID è l'IDP principale, tutte le app degli studenti e degli istituti di istruzione sono integrate con Microsoft Entra ID. Tutte le app di Microsoft 365 sono integrate anche con Microsoft Entra ID. Se Microsoft Entra Domain Services è in uso, viene sincronizzato anche con Microsoft Entra ID.
La funzionalità proxy SAML di Shibboleth si integra con Microsoft Entra ID. In Microsoft Entra ID, Shibboleth viene visualizzato come applicazione aziendale non inclusa nella raccolta. Le università possono ottenere l'accesso Single Sign-On (SSO) per le app CAS e possono partecipare all'ambiente InCommon. Shibboleth offre inoltre l'integrazione per i servizi directory LDAP (Protocollo Leggero di Accesso alle Directory).
Vantaggi
I vantaggi dell'uso di questa soluzione includono:
Autenticazione cloud per tutte le app: Tutte le app eseguono l'autenticazione tramite Microsoft Entra ID.
Facilità di esecuzione: Questa soluzione offre facilità di esecuzione a breve termine per le università che già usano Shibboleth.
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 multilaterale e cas, l'esperienza di autenticazione per gli utenti potrebbe non essere facile a causa dei reindirizzamenti tramite Shibboleth. Le opzioni per personalizzare l'esperienza di autenticazione per gli utenti sono limitate.
Integrazione limitata dell'autenticazione a più fattori di terze parti: Il numero di integrazioni disponibili per le soluzioni di autenticazione a più fattori di terze parti potrebbe essere limitato.
Nessun supporto granulare per l'accesso condizionale: Senza un supporto granulare per l'accesso condizionale, è necessario scegliere tra il denominatore meno comune (ottimizzare per un minor attrito ma avere controlli di sicurezza limitati) o il denominatore comune più elevato (ottimizzare i controlli di sicurezza a scapito dell'attrito dell'utente). La possibilità di prendere decisioni granulari è limitata.
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 |
| Configurazione di Shibboleth come proxy SAML | Articolo di Shibboleth che descrive come usare la funzionalità di proxy SAML per connettere Shibboleth IdP all'ID Entra Microsoft |
| Considerazioni sulla distribuzione dell'autenticazione multifattoriale di Microsoft Entra | Linee guida per la configurazione dell'autenticazione a più fattori Di Microsoft Entra |
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
Soluzione federativa multilaterale 3: Microsoft Entra ID con AD FS e Shibboleth