Come ho portato due siti comunali in Drupal alla misura 1.4.1, con i servizi su Maggioli

Con I.T.Svil (si apre in una nuova scheda) ho portato due siti comunali costruiti in Drupal 9 all'asseverazione della misura 1.4.1 del PNRR, «Esperienza del cittadino nei servizi pubblici». Il lavoro sui due Comuni è durato un anno, e la parte sull'accesso unico l'abbiamo chiusa nel 2025. Il tema grafico copriva una parte dei criteri di conformità; il resto è stato lavoro sui contenuti, sui servizi e sull'accesso del cittadino, ed è quello che racconto qui. I nomi dei due Comuni restano fuori; la piattaforma dei servizi era quella di Maggioli (si apre in una nuova scheda).

Che cosa chiede la misura 1.4.1 a un sito comunale?

La misura 1.4.1 finanzia i Comuni che adottano il modello di sito comunale disegnato da Designers Italia, e il finanziamento arriva dopo un'asseverazione: una verifica dei criteri di conformità del modello. I criteri sono raggruppati in famiglie, indicate con sigle del tipo C.SI.1.x: aspetto e struttura del sito, funzionalità come la prenotazione degli appuntamenti e la segnalazione dei disservizi, normativa su cookie, accessibilità e privacy, prestazioni misurate con Lighthouse, sicurezza del dominio e del protocollo.

Molti criteri entrano nel dettaglio della struttura. Le voci del menu di primo livello ci sono tutte e nell'ordine esatto del modello (C.SI.1.6), i titoli delle pagine di secondo livello seguono il suo vocabolario (C.SI.1.7), gli argomenti che classificano i contenuti vengono dal vocabolario europeo EuroVoc (C.SI.1.5). Ogni scheda di servizio mostra le voci obbligatorie nell'ordine indicato, compreso il tempo massimo di risposta dell'amministrazione (C.SI.1.3). Su un sito nato prima del modello, criteri come questi toccano quasi ogni pagina.

Per verificare i criteri in automatico c'è il PA Website Validator, pubblicato da Developers Italia. Uno strumento automatico però guarda la forma: che una scheda servizio abbia certi campi, che il menu abbia certe voci. Se i contenuti dietro quei campi sono vuoti o sbagliati, il sito passa il controllo e resta inutile per chi lo usa.

Basta un tema Drupal conforme al modello Comuni?

Il tema copre la parte visiva, e i contenuti restano da costruire. Sui due siti la base era il tema contrib bootstrap_italia, nella versione 2.8, con un sottotema nostro che aggiunge gli stili del modello Comuni. Con questa base i criteri grafici si soddisfano quasi da soli: i caratteri Titillium Web, Lora e Roboto Mono (C.SI.1.1), la libreria Bootstrap Italia su ogni pagina (C.SI.1.2), la struttura delle pagine.

I criteri che riguardano i contenuti invece dipendono da come il sito è costruito sotto: quali tipi di contenuto esistono, con quali campi, quali vocabolari controllati. Su entrambi i siti quella struttura era diversa da quella del modello, e qui è cominciato il lavoro vero.

Come si migrano i contenuti di un Comune sulle tipologie del modello?

Ho rifatto la struttura dei contenuti da capo e ci ho migrato sopra quello che c'era, con uno script custom. Il modello Comuni definisce le tipologie: servizi, uffici, documenti, notizie, eventi, luoghi, persone dell'amministrazione, ciascuna con i suoi campi e i suoi collegamenti. Ho creato in Drupal i tipi di contenuto e i vocabolari che le rappresentano, poi lo script ha riorganizzato i contenuti esistenti sui tipi nuovi.

La struttura di partenza dei due siti era molto lontana dal modello, e ricablarla è stata la parte complessa. Cambiavano insieme i tipi di contenuto, i campi, i vocabolari, l'alberatura del menu e i collegamenti fra le pagine: un servizio rimanda all'ufficio responsabile, un evento al luogo in cui si tiene, un documento al servizio a cui serve. Con uno script le regole di smistamento stanno in un posto solo, e si correggono e si rieseguono finché ogni contenuto arriva dove deve.

La migrazione è stata la parte meno visibile e quella con più decisioni. Un vecchio articolo poteva diventare una notizia, un documento o la pagina di un ufficio, a seconda di che cosa raccontava, e quella scelta riguarda il contenuto prima ancora della tecnica: per questo la migrazione è andata di pari passo con la formazione delle redazioni, di cui parlo più avanti.

Come arrivano sul sito i servizi della piattaforma Maggioli?

I servizi online dei due Comuni stavano sulla piattaforma di Maggioli: i pagamenti con pagoPA, la presentazione di istanze e pratiche, la prenotazione degli appuntamenti, che il modello chiede come funzione del sito (C.SI.2.1). Il modello Comuni chiede che il cittadino li trovi sul sito istituzionale, con la loro scheda, e non solo su un portale a parte.

Li abbiamo esposti in modo speculare: ogni servizio ha la sua scheda sul sito del Comune, e l'azione vera, pagare, presentare una domanda, prenotare, porta sulla piattaforma Maggioli.

Le schede le sincronizza ed espone Maggioli stesso, attraverso le sue API; il sito del Comune le consulta e le presenta con la struttura chiesta dal modello. Così il catalogo dei servizi resta in un posto solo, sulla piattaforma che li eroga, e un servizio aggiornato lì è aggiornato anche sul sito.

Il cittadino parte dal sito del Comune e arriva al servizio senza cercarlo altrove. Perché questo passaggio non obblighi a un secondo accesso, i due siti dovevano riconoscere lo stesso utente.

Perché costruire un accesso unico, se la misura non lo chiede?

Perché senza l'accesso unico il cittadino si autentica due volte, e senza l'uscita unica resta dentro uno dei due siti senza saperlo. La specifica pubblica di Maggioli sull'integrazione fra sito istituzionale e Sportello telematico lo dice in chiaro: l'accesso unico non è un requisito della misura 1.4.1, ma se lo si attiva serve anche l'uscita unica, perché una sessione rimasta aperta su un computer condiviso è un rischio per i dati personali.

Abbiamo costruito entrambe le cose, nei due sensi: chi entra dal sito del Comune è già dentro la piattaforma Maggioli, e viceversa; chi esce da uno esce anche dall'altro, con un logout remoto presso il provider dell'identità. È stata la parte più impegnativa del progetto e ci ha occupati per buona parte del 2025, per il numero di sistemi da far parlare fra loro. Il lavoro però è filato liscio: la documentazione di Maggioli sull'integrazione delle API era chiara ed esaustiva, e ogni passaggio del flusso aveva un riferimento scritto da seguire.

Perché un modulo Drupal scritto da zero?

I moduli esistenti risolvono un caso più semplice del nostro. Per SPID su Drupal esistono spid, che oggi non ha una release supportata, e samlauth, un modulo SAML generico e ben mantenuto. Entrambi presuppongono che Drupal parli direttamente con il fornitore dell'identità.

Nel nostro caso Drupal si trovava in mezzo a una catena: SPID e CIE li gestiva un intermediario di autenticazione esterno, il flusso passava da Shibboleth, e la sessione doveva valere anche sulla piattaforma Maggioli. Il modulo che ho scritto fa una cosa sola: riceve l'identità alla fine della catena, trova o crea l'utente Drupal e apre la sessione. L'area personale del sito si raggiunge da un percorso dedicato, /auth-service/login, che è la porta d'ingresso del modulo.

Perché Shibboleth in un container separato?

Per tenere il Service Provider SAML fuori dalla portata diretta di internet. Shibboleth è il componente che conclude il dialogo SAML e produce una sessione, con il suo cookie. Lo abbiamo messo in un container dedicato, e davanti a tutto c'era Traefik a instradare il traffico: le richieste di autenticazione arrivano al container, e solo dopo l'autenticazione passano a Drupal.

Il risultato è che il cookie di sessione generato da Shibboleth si legge solo dentro il container. Drupal riceve l'identità già verificata, e il Service Provider non è un servizio esposto da raggiungere e attaccare direttamente.

Come arriva un'identità SPID o CIE all'utente Drupal?

Con un solo dato: il codice fiscale. Quando il cittadino si autentica con SPID o con la CIE, l'intermediario verifica l'identità, Shibboleth chiude il flusso e il modulo riceve il codice fiscale. Con quello trova l'utente Drupal corrispondente, o lo crea al primo accesso.

Il codice fiscale era l'unica informazione di cui il sito aveva bisogno per riconoscere l'utente. Gli altri dati che un'identità digitale può portare, nome, email, indirizzo, al sito del Comune servivano a poco, e un dato che il sito tiene in meno è un dato in meno da proteggere.

Come si rispetta il criterio sulle prestazioni?

Il criterio C.SI.4.1 misura le pagine con Lighthouse, in modalità mobile, e chiede un punteggio di almeno 50 su tutte le pagine del sito. Sotto quella soglia il Comune pubblica un «Piano di miglioramento del sito», con le azioni previste per ogni voce che pesa sulle prestazioni e i tempi per realizzarle.

Il tema da solo porta a un sito conforme nell'aspetto, e la velocità va curata a parte. Sui due siti abbiamo fatto tuning e lavorato sulla cache, in modo da servire le pagine già pronte. Il criterio vale per tutte le pagine, quindi anche per gli elenchi di notizie ed eventi e per le schede che leggono i servizi dalla piattaforma Maggioli.

Che cosa serve a un Comune dopo l'asseverazione?

Una redazione che sappia usare il sito. Un sito conforme al modello il giorno dell'asseverazione smette di esserlo se dopo un anno le schede dei servizi sono ferme e gli eventi finiscono nelle notizie. Per questo abbiamo seguito le amministrazioni in diverse fasi formative: come si crea un contenuto della tipologia giusta, come si scrive la scheda di un servizio, e soprattutto come si gestisce un evento, con le date, il luogo e il collegamento al servizio o all'ufficio che lo organizza.

Lo staff che ha seguito la formazione era competente, e le sessioni sono filate senza intoppi: il tempo è andato tutto sulle regole del modello, cioè quale tipologia usare, quali campi compilare e come collegare un contenuto agli altri.

Che cosa cambia per un progetto che parte oggi?

Due cose, entrambe documentate. Dalla revisione del 28 marzo 2025 della specifica Maggioli, l'accesso con la CIE sulla piattaforma passa da OpenID Connect e non più da SAML2: un ponte nuovo va progettato su quel flusso. E Drupal 9 ha raggiunto la fine del supporto il 1 novembre 2023: un progetto che parte oggi parte da Drupal 10 o 11, con una versione di bootstrap_italia che li supporta.

Fonti

Tutte le fonti sono state consultate il 1 ottobre 2026.

• Criteri di conformità del modello di sito comunale (si apre in una nuova scheda), Designers Italia. Fonte primaria.
• PA Website Validator NG (si apre in una nuova scheda), Developers Italia. Fonte primaria.
• Integrazione Sportello telematico – sito istituzionale, rev. 6 (PDF) (si apre in una nuova scheda), Maggioli, 28/03/2025: accesso unico non obbligatorio per la 1.4.1, uscita unica, CIE in OpenID Connect. Fonte primaria.
• Bootstrap Italia per Drupal (si apre in una nuova scheda), drupal.org. Fonte primaria.
• Modulo spid (si apre in una nuova scheda) e modulo samlauth (si apre in una nuova scheda), drupal.org. Fonte primaria.
• Drupal 9 end of life (si apre in una nuova scheda), drupal.org. Fonte primaria.
• Il lavoro sui due siti con I.T.Svil, chiuso nel 2025 per la parte sull'accesso unico. Esperienza dell'autore.