IdP in the Cloud è il servizio di Identity as a Service per le organizzazioni della comunità GARR, conforme alle specifiche della Federazione IDEM e a quelle dell’interfederazione eduGAIN.

Un servizio che permette di accedere a migliaia di risorse web federate in sicurezza. Attraverso l’adesione al servizio è possibile ridurre drasticamente i costi dell’accesso federato dovuti all’integrazione del proprio sistema di gestione delle identità digitali in Federazione IDEM ed eduGAIN.

Il servizio è dedicato agli enti che hanno poche risorse a disposizione, poco personale IT, unità di piccole dimensioni o comunità partizionate (ad esempio gli IRCCS, Istituti di Ricovero e Cura a Carattere Scientifico). Ad oggi il servizio è fornito a 41 enti per circa 3.500 utenti e 8.000 autenticazioni l’anno. In termini assoluti, questi potrebbero non sembrare grandi numeri, ma è solo grazie ad Idp in the Cloud che è possibile garantire a questi enti l’accesso ad una serie di servizi GARR (Filesender, GARR Cloud, GARR Meet, SCARR, GINS), servizi di ricerca, servizi di prenotazione di risorse bibliografiche (ad es. Nilde), accesso alle riviste scientifiche, ecc.

Per saperne di più abbiamo rivolto alcune domande a Davide Vaghetti, coordinatore del servizio IDEM GARR AAI e a Marco Malavolti e Mario Di Lorenzo che si occupano dello sviluppo del servizio.

Perché avete sviluppato una nuova versione di IdP in the Cloud e non vi siete limitati ad aggiornare l’attuale?

Vaghetti: I motivi fondamentali per cui abbiamo deciso di sviluppare una nuova versione sono due: la necessità di implementare nuovi requisiti e la volontà di rendere molto più efficiente e resiliente il servizio.

Quante risorse sono attualmente necessarie per garantire un servizio efficiente?

Malavolti: Nella versione 2 di IdP in the Cloud, così come nella sua prima versione, il servizio “costava” a GARR la creazione di 1 macchina virtuale (dotata di 2 vCPU, 4 GB di RAM e 20 GB di Disco) per ciascuno dei 41 enti aderenti. Con un rapido calcolo, considerando anche il fatto che è necessario ridondare tutte le istanze per la continuità operativa, otteniamo 168 vCPU, 328GB di RAM e 1640 GB di Disco.

Come è stato sviluppato IdP in the Cloud 3.0?

Vaghetti: A giugno 2022 abbiamo iniziato la raccolta dei requisiti mentre il processo di sviluppo vero e proprio è partito a luglio dello stesso anno. Abbiamo riprogettato il servizio da zero pensandolo molto diversamente dal precedente. In primo luogo, IdP in the Cloud 3.0 è “multi-tenant”, ossia un’unica piattaforma in grado di fornire il servizio a più organizzazioni partizionandolo per ciascuna di esse. Contemporaneamente abbiamo deciso di sviluppare un sistema di identity management dedicato e sviluppato in casa dato che quello precedentemente utilizzato non supportava adeguatamente i nuovi requisiti del servizio. Tra le nuove caratteristiche implementate, vanno menzionate la Multi-Factor Authentication (MFA) e la verifica dell’accreditamento, ossia il processo tramite il quale si inseriscono gli utenti sulla piattaforma, via API (Application Programming Interface), che seguirà processi di verifica differenziati a seconda di chi lo utilizza. Ad esempio nel caso degli IRCCS, la verifica dell’accreditamento avverrà tramite la consultazione del Workflow della Ricerca.

Come è composta l’architettura e quali sono i maggiori cambiamenti della nuova versione?

Malavolti: Dopo anni di onorato servizio di sviluppo di ricette per creare i singoli IdP in the Cloud v1 (Puppet) e v2 (Ansible), la nuova v3 porta con sé un notevole cambiamento, non solo dal punto di vista delle tecnologie usate per il deployment (Docker), ma soprattutto per il cambio di Framework SAML che passa da Shibboleth (di cui possiamo fregiarci del titolo di maestri indiscussi nell’installazione e nella configurazione, grazie ai nostri How-to e al notevole lavoro che facciamo con i nostri utenti di Federazione IDEM) a SimpleSAMLphp, framework SAML che ha il supporto multi-tenant (una istanza, più organizzazioni).

La nuova versione di IdP in the Cloud offrirà il supporto al Multi-Factor Authenticator che aumenterà almeno di un grado il livello di sicurezza delle identità divulgate alle risorse federate. La nuova architettura prevede la netta separazione di front-end e back-end. Il front-end comprende l’Identity Provider (il sistema di autenticazione federata), l’Identity Management System e l’interfaccia di gestione del secondo fattore di autenticazione. Il back-end invece è composto dal Directory Server ed il Database. Ogni componente è ridondato e bilanciato se necessario. Quest’architettura produrrà un notevole guadagno dal punto di vista delle risorse impiegate per erogare il servizio IdP in the Cloud.

Quante risorse si potrebbero risparmiare sulla versione multi-tenant rispetto a quella attuale, a parità di prestazioni?

Malavolti: IdP in the Cloud v3 utilizzerà 4 container node dotati ciascuno di 8 vCPU, 32 GB di RAM e 256 GB di spazio disco per un totale di 32 vCPU, 256 GB di RAM e 1024 GB di spazio disco. Tali sono le risorse hardware necessarie per offrire il servizio, a parità di prestazioni, agli attuali 41 istituti aderenti e a quelli futuri.

Ci puoi dare qualche informazione in più sulla nuova interfaccia e sulle novità più rilevanti per gli utenti?

Di Lorenzo: L’interfaccia utente della versione 2 di IdP in the Cloud è stata completamente rivisitata. La nuova interfaccia è basata sul tema di Bootstrap Italia per la Pubblica Amministrazione, sviluppato e supportato da Developers Italia. Il punto di forza è la riconoscibilità: l’utente si ritroverà la stessa interfaccia sia quando utilizzerà l’Identity Management System che quando effettuerà l’accesso sull’Identity Provider. Le novità più rilevanti riguarderanno invece gli amministratori degli Identity Provider: abbiamo deciso di abbandonare l’attuale interfaccia, phpLDAPAdmin, utilizzata per operare su LDAP, in favore di un’interfaccia intelligente e molto più semplice da utilizzare.