Panoramica dell'architettura di base
Microsoft è spesso in contatto con università di ricerca che operano in ambienti ibridi in cui le applicazioni sono basate su cloud o ospitate in locale. In entrambi i casi, le applicazioni possono usare vari protocolli di autenticazione. In alcuni casi, questi protocolli stanno raggiungendo la fine del proprio ciclo di vita o non forniscono il livello di sicurezza richiesto.
Le applicazioni guidano gran parte della necessità di diversi protocolli di autenticazione e meccanismi di gestione delle identità (IdM).
In ambienti universitari di ricerca, le app di ricerca spesso guidano i requisiti di IdM. Un'università potrebbe usare un provider di federazione, ad esempio Shibboleth, come provider di identità primario (IdP). In tal caso, Microsoft Entra ID viene spesso configurato per la federazione con Shibboleth. Se anche app Microsoft 365 sono in uso, Microsoft Entra ID consente di configurare l'integrazione.
Le applicazioni usate nelle università di ricerca operano in varie parti del footprint IT complessivo:
Le applicazioni di ricerca e federazione multilaterale sono disponibili tramite InCommon ed eduGAIN.
Le applicazioni di libreria forniscono l'accesso a journal elettronici e ad altri provider di contenuti elettronici.
Alcune applicazioni usano protocolli di autenticazione legacy come il Servizio di autenticazione centrale per abilitare l'accesso Single Sign-On.
Le applicazioni di studenti e docenti usano spesso più meccanismi di autenticazione. Ad esempio, alcuni sono integrati con Shibboleth o altri provider di federazione, mentre altri sono integrati con Microsoft Entra ID.
Le applicazioni Microsoft 365 sono integrate con Microsoft Entra ID.
Windows Server Active Directory potrebbe essere in uso e sincronizzato con Microsoft Entra ID.
Lightweight Directory Access Protocol (LDAP) è in uso in molte università che potrebbero avere una directory LDAP esterna o un registro delle identità. Questi registri vengono spesso usati per ospitare attributi riservati, informazioni sulla gerarchia dei ruoli e persino determinati tipi di utenti (ad esempio, candidati).
Active Directory locale, o una directory LDAP esterna, viene spesso usata per abilitare l'accesso con credenziali singole per applicazioni non-Web e vari accessi non-Microsoft del sistema operativo.
Problemi relativi all'architettura di base
Spesso, le architetture di base si evolvono nel corso del tempo, introducendo maggiore complessità e rigidità nel modello e la capacità di effettuare aggiornamenti. Di seguito sono riportate alcune delle problematiche relative all'uso dell'architettura di base:
Difficoltà a reagire a nuovi requisiti: la presenza di un ambiente complesso rende difficile adattarsi rapidamente e tenersi al passo con le normative e i requisiti più recenti. Ad esempio, se si dispone di app in molte posizioni e tali app sono connesse in modi diversi con diversi IDM, è necessario decidere dove individuare i servizi di autenticazione a più fattori e come imporre l'autenticazione a più fattori.
L'istruzione superiore sperimenta anche la titolarità frammentata del servizio. Le persone responsabili di servizi chiave come la pianificazione di risorse aziendali, i sistemi di gestione dell'apprendimento, la divisione e le soluzioni di reparto potrebbero opporsi a eventuali cambiamenti o modifiche ai sistemi che operano.
Non è possibile sfruttare tutte le funzionalità di Microsoft 365 per tutte le app (ad esempio, Intune, accesso condizionale, senza password): molte università desiderano passare a cloud e usare i propri investimenti esistenti in Microsoft Entra ID. Tuttavia, con un provider di federazione diverso come idP principale, le università non possono sfruttare tutte le funzionalità di Microsoft 365 per le altre app.
Complessità di una soluzione: ci sono molte componenti da gestire. Alcune componenti si trovano nel cloud e alcune sono in locale o in istanze di infrastruttura distribuita come servizio (IaaS). Le app vengono gestite in molte Località. Per l'utente, questa esperienza può risultare frammentaria. Ad esempio, gli utenti possono a volte visualizzare una pagina di accesso Shibboleth e altre volte una pagina di accesso a Microsoft Entra.
Vengono presentate tre soluzioni per risolvere questi problemi, le quali rispondono al tempo stesso ai seguenti requisiti:
Possibilità di partecipare a federazioni multilaterali come InCommon ed eduGAIN
Possibilità di supportare tutti i tipi di app (anche app che richiedono protocolli legacy)
Possibilità di supportare directory esterne e archivi di attributi
Le tre soluzioni saranno presentate in ordine, dalla più consigliabile alla meno consigliabile. Ognuna di esse soddisfa i requisiti, ma introduce compromessi che sono previsti in un'architettura complessa. In base ai propri requisiti e punto di partenza, selezionare la soluzione più adatta all'ambiente. È fornito anche uno schema ad albero decisionale per facilitare questa scelta.
Passaggi successivi
Vedere questi articoli correlati sulla federazione multilaterale:
Introduzione alla federazione multilaterale
Federazione multilaterale Soluzione 1: Microsoft Entra ID con Cirrus Bridge
Federazione multilaterale Soluzione 3: Microsoft Entra ID con AD FS e Shibboleth
Schema ad albero decisionale della federazione multilaterale