Su una griglia di calcolo scientifica l’identità dell’utente è un certificato X.509 emesso da una certification authority accreditata, non una coppia username/password gestita dall’applicazione. Da questo discende quasi tutto il modo in cui si costruisce un portale web sopra una griglia come GRID.IT. Il lavoro più delicato non sta nell’interfaccia: sta nel ponte fra browser e infrastruttura di sicurezza.

Contesto

GRID.IT è il progetto finanziato dal programma FIRB (Fondo per gli Investimenti della Ricerca di Base) del Ministero dell’Istruzione, dell’Università e della Ricerca, coordinato da Domenico Laforenza all’ISTI-CNR di Pisa (Istituto di Scienza e Tecnologie dell’Informazione “Alessandro Faedo”), con la partecipazione di INFN, CNR, INAF, INGV e di diverse università. L’obiettivo dichiarato è un’infrastruttura di calcolo distribuito per la ricerca scientifica italiana.

Sul piano del software, lo stack di una griglia di questo tipo è interamente open source: il middleware Globus Toolkit (la versione 4.0 è uscita nell’aprile 2005, costruita su WSRF e sull’architettura OGSA) e il middleware gLite sviluppato nel progetto europeo EGEE. Il sistema operativo è Linux, e la gran parte dei componenti — dal gatekeeper ai servizi di gestione dati — gira su distribuzioni Scientific Linux. Per portale si intende qui il livello con cui un ricercatore sottomette job e consulta i risultati da un browser, senza installare sulla propria macchina il client a riga di comando della griglia.

Il problema dell’autenticazione

Il modello di sicurezza è la Grid Security Infrastructure (GSI), introdotta dal progetto Globus alla fine degli anni Novanta. GSI usa certificati X.509 e TLS per l’autenticazione, e aggiunge un meccanismo di delega: il proxy certificate, standardizzato nel 2004 dalla RFC 3820. Il proxy è un certificato a vita breve (di norma dodici ore) firmato dal certificato dell’utente, e porta con sé una chiave privata non protetta da passphrase. Esiste perché un job che gira per ore su un nodo remoto deve potersi autenticare verso altri servizi della griglia — uno storage element, un altro computing element — senza che l’utente sia lì a digitare la passphrase ogni volta.

Da qui il problema concreto del portale. L’utente arriva con un browser. Per sottomettere lavoro gli serve un proxy valido. Ma per generare il proxy serve la chiave privata dell’utente, che per buona prassi non dovrebbe mai uscire dalla macchina del proprietario. Un portale che chiedesse all’utente di caricare la propria chiave privata sul server romperebbe il presupposto su cui si regge l’intera fiducia della griglia.

Architettura

Nell’ecosistema delle griglie la soluzione è interporre un servizio di credenziali fra portale e utente. Lo schema è quello di MyProxy, nato all’NCSA: l’utente deposita in anticipo un proxy a vita più lunga su un repository MyProxy, protetto da passphrase; il portale, al momento del bisogno, recupera da quel repository un proxy a vita breve e lo usa per agire al posto dell’utente. La chiave privata di lunga durata dell’utente non passa mai dal portale.

Sul lato dell’interfaccia, il portale GENIUS sviluppato all’INFN è l’esempio italiano di riferimento: un front-end web costruito su Apache che traduce le azioni dell’utente in comandi del middleware sottostante, mediando proprio attraverso MyProxy. La logica del portale fa poca presentazione e molto altro: orchestra le credenziali, costruisce la job description, sottomette al resource broker e traccia lo stato.

C’è poi il livello dell’autorizzazione, distinto da quello dell’autenticazione. Sapere chi è l’utente non basta: bisogna sapere a quale virtual organisation appartiene e con quali diritti. Lo fornisce VOMS (Virtual Organisation Membership Service), che inserisce nel proxy degli attributi firmati su gruppi e ruoli. Anche questo il portale deve maneggiarlo: un proxy senza estensioni VOMS è autenticato ma può non essere autorizzato a fare nulla.

Punto critico

Il punto critico è la certification authority. Tutto il modello di fiducia si regge sul fatto che ogni paese abbia una CA accreditata e che le CA si riconoscano fra loro attraverso una federazione di trust. Per l’Italia la CA accreditata della griglia è quella dell’INFN, il cui Certificate Policy / Certification Practice Statement è coordinato a livello europeo da EUGridPMA, l’organismo che cura il tessuto di fiducia per l’autenticazione e-Science in Europa, a sua volta parte di IGTF (International Grid Trust Federation).

La conseguenza pratica è che un portale non può improvvisare la gestione delle identità. Deve fidarsi esattamente dell’insieme di CA che la federazione riconosce, distribuire i certificati radice corretti, rispettare le politiche di revoca e di durata. Basta un certificato di CA non aggiornato, o una lista di revoca scaduta, e l’autenticazione smette di funzionare per tutti — oppure, peggio, continua a funzionare quando non dovrebbe. Gestire la CA, in un progetto come GRID.IT, è quindi un compito a sé, con responsabilità operative che non si esauriscono nello scrivere codice.

Implicazioni

Per chi costruisce il livello web la conseguenza è che il portale è soprattutto un mediatore di sicurezza. Le scelte che pesano davvero — depositare i proxy via MyProxy, distribuire i trust anchor delle CA, integrare gli attributi VOMS, rispettare la RFC 3820 — sono scelte di infrastruttura, e l’interfaccia grafica vive sopra di esse. Qui lo stack interamente open source pesa per un motivo pratico, non ideologico: ogni componente del middleware è ispezionabile, e così si verifica fino in fondo il comportamento dell’autenticazione attraverso i vari livelli. Cosa indispensabile quando una credenziale firmata da una CA nazionale attraversa quattro o cinque servizi prima che un job parta. Il portale GRID.IT su stack Linux/Apache/Zope e la certification authority del progetto — costruita su OpenCA, con directory e autenticazione su OpenLDAP, per emettere i certificati X.509 di nodi e utenti, distinta dalla CA nazionale accreditata dell’INFN — sono fra le componenti realizzate da noze nel progetto, descritte nell’insight relativo: https://www.noze.it/insights/gridit-firb/.

Limiti

Quanto descritto riguarda autenticazione e autorizzazione, non l’usabilità complessiva di una griglia. Restano fuori dal quadro lo scheduling, l’affidabilità del data movement su WAN, la riproducibilità dei job e la gestione delle code, che pesano sull’esperienza del ricercatore almeno quanto il modello di sicurezza. E la centralità del proxy a vita breve risolve la delega ma introduce un punto fragile: un proxy sottratto resta utilizzabile finché non scade, e su questo le politiche delle CA stanno ancora evolvendo. Il portale rende la griglia raggiungibile da un browser; non la rende semplice.

Immagine di copertina: Fila di armadi rack pieni di server e cavi nel centro di calcolo del CERN, parte della griglia di calcolo scientifica — foto di Bigfoot~commonswiki, pubblico dominio — https://commons.wikimedia.org/wiki/File:Cern_computer_grid.jpg