Integrare SPID e CIE in un sito WordPress: opzioni reali e raccomandazioni

Perche' WordPress e' un caso speciale

WordPress nasce come CMS pubblico, con un sistema utenti per blogger/redattori. Lo SPID, invece, autentica cittadini per servizi specifici. Integrare le due cose richiede di:

• creare un secondo "registro utenti" o estendere quello di WordPress;
• aggiungere endpoint SAML (AuthnRequest, ACS, SLO, metadata) come pagine virtuali servite dal core o da un plugin;
• gestire correttamente la sessione: SPID e WordPress devono condividere lo stato di login;
• essere conformi alle Linee Guida AgID, in particolare il bottone "Entra con SPID" deve essere quello ufficiale (lo "smart button" SPID con scelta IdP).

Opzione A: plugin diretti (es. spid-wordpress)

Esistono alcuni plugin SPID per WordPress, di cui il piu' noto e' spid-wordpress (originariamente sviluppato dal Team Digitale, oggi mantenuto dalla comunita'). Pro:

• installazione standard via wp-admin;
• integrazione diretta con il sistema utenti di WordPress;
• botton ufficiale SPID gia' incluso, conforme alle regole grafiche AgID.

Contro:

• manutenzione lasciata alla comunita': non sempre allineato agli avvisi tecnici AgID piu' recenti;
• configurazione SAML interna che richiede comunque competenze (certificati, EntityID, ACS URL);
• nessuna copertura CIE: l'integrazione CIE richiede un plugin separato o sviluppo custom;
• scalabilita' limitata: il salvataggio attributi SAML come user meta WordPress diventa pesante a volumi alti.

Opzione B: middleware esterno + WordPress come solo frontend

Approccio piu' moderno: un servizio esterno (auth gateway) gestisce SPID/CIE/eIDAS. Dopo il login, redirect a WordPress con un token sicuro (JWT firmato o SAML attribute statement) che WordPress traduce in una sessione WordPress. Vantaggi:

• WordPress resta pulito, nessun codice SAML al suo interno;
• il gateway puo' coprire SPID + CIE + IT Wallet con la stessa API;
• aggiornamenti AgID assorbiti dal gateway, non dal vostro WordPress;
• multi-sito: un solo gateway puo' servire piu' WordPress (es. tutti i siti dei Comuni di una Unione).

Il plugin necessario su WordPress diventa molto piccolo: riceve il token, fa la wp_set_auth_cookie, crea l'utente se non esiste. Pochi centinaia di righe di codice.

Opzione C: SaaS auth-as-a-service white-label

Variante della B: il gateway esterno e' un servizio commerciale (come IngressoDigitale) che fornisce gia' la conformita' AgID, il bottone SPID/CIE, la gestione utenti, la statistica. Vantaggi rispetto al middleware self-hosted:

• nessuna gestione di certificati, metadata, validator AgID;
• SLA contrattuali sulla disponibilita';
• aggiornamenti normativi inclusi;
• statistiche di accesso e reportistica AgID gia' pronte.

Confronto pratico

Aspetto	Plugin diretto	Middleware self-hosted	SaaS
Setup iniziale	3-5 giorni	2-4 settimane	2-3 giorni
Costo annuale	0 - 500 EUR	8.000 - 20.000 EUR (manutenzione)	2.000 - 12.000 EUR (canone)
Conformita' AgID	Da verificare manualmente	Lavoro continuo	Inclusa
CIE	Separato	Integrato	Integrato
Scalabilita'	Limitata	Buona	Cloud
Indipendenza	Massima	Massima	Vendor lock-in basso

Passi pratici per integrazione plugin

1. Pre-requisiti server

WordPress deve girare su PHP 8.1+, con estensioni: openssl, xml, dom, mcrypt (per versioni vecchie del plugin), curl. HTTPS obbligatorio.

2. Installazione plugin

Da wp-admin > Plugin > Aggiungi nuovo, cercare "SPID WordPress" e installare la versione ufficiale. Attenzione: esistono fork non aggiornati. Verificare data ultima release.

3. Generazione certificati

Da terminale lato server: openssl req -newkey rsa:2048 -nodes -x509 -days 365 -keyout sp.key -out sp.crt -subj "/C=IT/O=NomeEnte/CN=spid.dominio.it"

I file vanno collocati nella cartella plugin (verificare path nelle istruzioni della versione installata) e referenziati dalla configurazione.

4. Configurazione EntityID e metadata

L'EntityID deve essere un URL HTTPS unico che generera' i metadata, tipicamente https://www.dominio.it/wp-content/plugins/spid-wordpress/metadata/ o un URL configurabile.

5. Test con IdP demo

Prima dell'accreditamento, usare il validator AgID demo SPID (https://demo.spid.gov.it/validator) come IdP di test. Questo permette di verificare il flusso end-to-end senza dover ancora avere l'accreditamento.

6. Accreditamento

Una volta che i test demo funzionano, procedere con la richiesta ad AgID secondo la procedura di accreditamento.

Anti-pattern comuni

• Caricare i metadata su file statico senza firma: AgID rifiuta. Devono essere firmati.
• Permettere registrazione utenti WordPress standard insieme allo SPID: confonde gli utenti e crea ambiguita' di sicurezza. Per servizi accessibili solo via SPID/CIE, disabilitare totalmente la registrazione classica.
• Salvare il PIN/password SPID: il SP non vede mai le credenziali utente. Lo SP riceve solo l'attribute statement firmato dall'IdP.
• Logout solo WordPress: bisogna effettuare anche il Single Logout SAML verso l'IdP, altrimenti l'utente resta loggato sull'IdP.