Panoramica dell'architettura di base

Microsoft parla spesso con università di ricerca che operano in ambienti ibridi in cui le applicazioni sono basate sul cloud o ospitate in locale. In entrambi i casi, le applicazioni possono usare vari protocolli di autenticazione. In alcuni casi, questi protocolli raggiungono la fine del ciclo di vita o non forniscono il livello di sicurezza richiesto.

Le applicazioni supportano gran parte della necessità di protocolli di autenticazione diversi e meccanismi di gestione delle identità (IdM).

Negli ambienti universitari di ricerca, le app di ricerca spesso guidano i requisiti di IdM. Un'università potrebbe usare un provider federativo, ad esempio Shibboleth, come provider di identità primario (IdP). In tal caso, Microsoft Entra ID viene spesso configurato per la federazione con Shibboleth. Se sono in uso anche Microsoft 365 Apps, 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 ai journal elettronici e ad altri provider di contenuti elettronici.

• Alcune applicazioni usano protocolli di autenticazione legacy, ad esempio Il servizio di autenticazione centrale per abilitare l'accesso Single Sign-On.

• Le applicazioni degli studenti e degli istituti di istruzione 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 anche determinati tipi di utenti, ad esempio i 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

Le architetture di base si evolvono spesso nel tempo, introducendo complessità e rigidità per la progettazione e la possibilità di aggiornare. Di seguito sono riportate alcune delle problematiche relative all'uso dell'architettura di base:

• Difficile reagire ai nuovi requisiti: La presenza di un ambiente complesso rende difficile adattarsi rapidamente e tenere il passo con le normative e i requisiti più recenti. Ad esempio, se si dispone di app in molte posizioni e queste app sono connesse in modi diversi con diversi IDM, è necessario decidere dove individuare i servizi di autenticazione a più fattori e come applicare l'autenticazione a più fattori.

  Anche l'istruzione superiore sperimenta la proprietà frammentata del servizio. Le persone responsabili di servizi chiave come la pianificazione delle risorse aziendali, i sistemi di gestione dell'apprendimento, la divisione e le soluzioni di reparto potrebbero resistere agli sforzi per modificare o modificare i 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à vogliono passare al cloud e usare gli investimenti esistenti in Microsoft Entra ID. Tuttavia, con un provider federativo diverso come idP principale, le università non possono sfruttare tutte le funzionalità di Microsoft 365 per le altre app.

• Complessità di una soluzione: Sono disponibili molti componenti da gestire. Alcuni componenti si trovano nel cloud e alcuni sono in locale o in istanze IaaS (Infrastructure as a Service). Le app vengono utilizzate in molti luoghi. Per l'utente, questa esperienza può essere disgiunta. Ad esempio, gli utenti a volte vedono una pagina di accesso Shibboleth e altre volte vedono una pagina di accesso a Microsoft Entra.

Vengono presentate tre soluzioni per risolvere queste sfide, risolvendo al tempo stesso i requisiti seguenti:

• Possibilità di partecipare a federazioni multilaterali come InCommon ed eduGAIN

• Possibilità di supportare tutti i tipi di app (anche le app che richiedono protocolli legacy)

• Possibilità di supportare directory esterne e archivi di attributi

Presentiamo le tre soluzioni in ordine, dal più preferito al meno preferito. Ognuno soddisfa i requisiti, ma introduce decisioni di compromesso previste in un'architettura complessa. In base ai requisiti e al punto di partenza, selezionare quello più adatto all'ambiente. Forniamo anche un albero delle decisioni per facilitare questa decisione.

Passaggi successivi

Vedere questi articoli correlati sulla federazione multilaterale:

Introduzione alla federazione multilaterale

Soluzione federativa multilaterale 1: Microsoft Entra ID con Cirrus Bridge

Soluzione federativa multilaterale 2: Microsoft Entra ID con Shibboleth come proxy SAML (Security Assertion Markup Language)

Soluzione federativa multilaterale 3: Microsoft Entra ID con AD FS e Shibboleth

Albero decisionale multilaterale della federazione