All’Università di Napoli Parthenope un complesso lavoro per uniformare i sistemi di accesso alle tante applicazioni disponibili online

di Vincenzo Abate, Antonello Cioffi, Giuliano Intrito, Nunzio Napolitano, Luigi Sgaglione
Servizi Informatici Ateneo, Università Parthenope

Il contesto tecnologico dell’Università di Napoli “Parthenope” negli ultimi tempi è stato caratterizzato da una crescente presenza di servizi e applicazioni. Ciò ha comportato la necessità di porre una maggiore attenzione alla corretta gestione degli utenti affinché possano accedere in modo semplice e sicuro alle risorse online. Servizi come Microsoft 365 o come quelli erogati da CINECA (ESSE3, UGOV, IRIS), il Wi-Fi (sia interno che eduroam) o piattaforme per l’e-learning come Moodle, nonché tutti i servizi GARR accessibili tramite IDEM e eduGAIN sono solo alcuni esempi, a cui si aggiungono le recenti adozioni di SPID e CIE.

Tutto ciò, ha reso necessario un processo di riorganizzazione delle identità degli utenti sia per renderne più sostenibile la gestione, sia per migliorare la user experience, ad esempio, attraverso la creazione un’unica credenziale di accesso. Inoltre, tale processo ha permesso non solo di migliorare gli aspetti di sicurezza ma anche di incrementare l’efficienza del contesto IT “svecchiando” e ottimizzando l’infrastruttura.

Scenario iniziale

La situazione da cui si è partiti comprendeva diversi sistemi che non prevedevano una gestione coordinata e univoca delle identità con evidenti criticità e ripercussioni. Per la memorizzazione delle identità erano presenti due server LDAP: uno per gli studenti (alimentato da CINECA) ed uno per il personale di Ateneo. Entrambi i server e le relative copie di backup erano gestiti internamente dallo staff universitario. Era inoltre presente un Identity Provider (IdP) Shibboleth, opportunamente configurato per autenticare gli utenti sui server LDAP e federato con i servizi IDEM ed eduGAIN.

Per la fase di autenticazione, alcuni servizi utilizzavano direttamente i server LDAP, mentre altri l’IdP. Le reti Wi-Fi, invece, utilizzavano un’architettura composta da diversi server “FreeRADIUS” anch’essi interfacciati ai server LDAP per l’autenticazione.

Gli accessi ai numerosi servizi Microsoft offerti dall’università (email, Teams, OneDrive, ecc.) erano gestiti attraverso Azure Active Directory (AAD). LDAP e AAD erano servizi del tutto slegati tra di loro dove era compito dell’operatore garantire la consistenza dei dati tra i due sistemi.

Il progetto

Dopo un’attenta analisi dell’architettura esistente e dopo aver effettuato le opportune verifiche di compatibilità di tutte le procedure con i sistemi di gestione identità centralizzate, sono stati ipotizzati diversi possibili scenari valutandone pro e contro.

Come soluzione più adatta è stata individuata quella di tipo ibrido, ovvero con la presenza di due elementi chiave: il primo è il database Active Directory (AD) on-premise utilizzato come elemento master per gestire tutte le identità delle utenze; il secondo è il servizio Azure AD utilizzato per permettere l’accesso a tutti i servizi del mondo Microsoft 365. I due elementi sono tra loro sincronizzati mediante l’utilizzo del servizio Azure Active Directory Connect (AAD Connect). L’Active Directory è interrogato direttamente solo per la gestione della rete Wi-Fi. Tutti gli altri servizi interrogano invece l’AD indirettamente, ovvero, mediante l’IDP ed in Single Sign-On (SSO). L’architettura server on-premise è costituita da due Domain Controller in “hot replacement” più una macchina per AD Connect.

Diverse sono state le motivazioni che hanno portato alla scelta di tale soluzione, tra cui la più importante è stata quella relativa alla riduzione del rischio del vendor lock-in” nei confronti di Microsoft. Infatti, l’architettura con un AD on-premise (master) in aggiunta ad AAD, piuttosto che una soluzione del tutto cloud basata su AAD, consente la riconfigurazione dei servizi, con effort limitato, nel caso di un eventuale abbandono da parte dell’Ateneo dei servizi cloud Microsoft. La stessa motivazione è alla base della scelta di configurare l’IdP con l’AD on-premise in luogo del corrispettivo cloud AAD.

Le fasi di realizzazione

La realizzazione di tale soluzione ha reso necessaria la configurazione di un ambiente parallelo a quello in produzione dove poter di volta in volta fare tutti i test del caso e quindi decidere cosa rendere effettivamente operativo. Si è scelto di utilizzare come campo identificativo un codice alfanumerico dell’utente. Ogni singola utenza, quindi, si identificherà sempre con lo stesso codice indipendentemente dalla sua carriera accademica o professionale, a differenza di quanto avveniva con la precedente architettura, dove il cambio profilo (ad esempio, da studente a dottorando) provocava la generazione di account multipli associati alla stessa persona fisica che risultavano di difficile gestione dalle applicazioni. Nella nuova configurazione invece, ciò che può cambiare nel tempo sono solo alcuni attributi, tra i quali l’e-mail principale, le e-mail di alias e il ruolo.

Le fasi di progettazione e realizzazione sono state molto delicate e diverse scelte sono state condizionate dalla presenza della configurazione automatica delle utenze degli studenti da parte di CINECA. Questo ci ha vincolati a raggruppare gli utenti sotto la stessa unità organizzativa e a dover definire uno specifico attributo associato al ruolo.

L‘importazione degli utenti è stata la fase più delicata ed ha richiesto sia una bonifica che una fusione delle utenze provenienti dai vari sistemi in un unico database. È stato quindi necessario stabilire gli attributi da utilizzare e la corrispondenza con quelli usati in precedenza. La base dati creata è stata poi importata nell’Active Directory di Ateneo mediante opportuni comandi PowerShell.

Il software AADConnect, poi, ha permesso di sincronizzare le informazioni presenti sull’AD di Ateneo con Azure AD. La sincronizzazione è stata monodirezionale da AD verso AAD, fatta eccezione per la password. Questa scelta ha costretto tutti gli utenti a cambiare la password di accesso ai servizi Microsoft. La nuova password è diventata però la credenziale unica necessaria per accedere a tutti i servizi.

Il cambio di password è sempre un aspetto molto delicato perché spesso le comunicazioni tecniche non vengono lette e, nonostante un’estesa campagna informativa, la maggior parte delle richieste di assistenza è stata: “Non riesco ad accedere alla posta, non ricordo la password”.

Abbiamo considerato, infine, l’importanza della sicurezza nella definizione di nuovi criteri per le password (lunghezza minima, complessità etc..) e abbiamo configurato il servizio Azure Password Protection. Un grande lavoro è stato fatto anche per allineare questi criteri con quelli previsti dai servizi erogati da CINECA.

L’Identity Provider Shibboleth è stato configurato per effettuare il binding su AD, inoltre i servizi SPID e CIE sono stati abilitati utilizzando un approccio di tipo proxy realizzato mediante un Service Provider (SP) Shibboleth opportunamente configurato per fare da tramite tra i provider SPID e CIE e l’IdP di Ateneo.

Sviluppi futuri

La soluzione messa in atto apre diversi scenari futuri. Il principale è quello di avere una gestione centralizzata di tutte le macchine utente dell’Ateneo mediante la relativa registrazione a dominio. I vantaggi sarebbero evidenti sia dal punto di vista della gestione che della sicurezza. Verso questo obiettivo, stiamo già redigendo un piano di migrazione che prevede l’utilizzo degli strumenti Intune ed Autopilot di Microsoft.