Migrare da una libreria SPID PHP a IngressoDigitale: la guida

Lavori con una libreria SPID open source in produzione? Capiamo i pro e i contro, e ti mostriamo perché tante software house ci stanno migrando sopra. Con un pattern di compatibilità che non ti obbliga a riscrivere il tuo codice.

Una premessa onesta sulle librerie SPID PHP open source

Le librerie SPID PHP open source nate negli ultimi anni sono progetti di valore: hanno permesso a centinaia di sviluppatori italiani di non scrivere XMLDSig da zero e di portare SPID nei propri applicativi senza partire da un foglio bianco. Va riconosciuto il lavoro della community che le mantiene.

Detto questo, gli ultimi anni hanno fatto emergere alcuni limiti strutturali quando si passa da «progetto demo per 50 utenti» a «produzione per migliaia di utenti su un ente reale». Vediamoli.

Perché una libreria open non basta in produzione

1. Manutenzione discontinua

I repository community hanno periodi di attività e di pausa, dipendenti dalla disponibilità dei manutentori volontari. Quando AgID aggiorna le Linee Guida (è capitato più volte negli ultimi due anni), tu devi prima attendere la PR community, poi testarla, poi rilasciarla sui tuoi clienti. Tempo medio: 4-8 settimane di esposizione su una regola nuova.

2. Sicurezza affidata a te

La libreria ti dà i mattoni (validazione firma, gestione metadata). Ma chi gestisce il caso replay? Chi cifra il certificato privato? Chi ruota i certificati X.509 che scadono a due anni? Tutto questo è codice che devi scrivere e mantenere tu. Su un singolo Service Provider si gestisce, su 10 SP (software house multi-cliente) diventa un secondo mestiere.

3. Scalabilità SAML

SAML 2.0 ha pattern di scaling specifici (gestione AssertionID cache distribuita, session affinity per LogoutResponse asincrono). Gestire questo su Redis Cluster + load balancer non è banale. La libreria non lo fa per te.

4. Audit log compliance

AgID nelle Linee Guida richiede log con specifiche precise (timestamp UTC, hash asserzione, IdP, livello, esito). Generarli è facile, conservarli 24 mesi e renderli interrogabili per un controllo AgID è meno facile. La libreria genera il log, ma il resto è tua infrastruttura.

5. Onboarding nuovi IdP

Quando nasce un nuovo IdP SPID, va aggiunto il suo entityID nel metadata di test, poi in produzione. Spesso significa una release software per tutti i tuoi clienti.

Cosa cambia con IngressoDigitale

Aspetto	Libreria SPID PHP open	IngressoDigitale
Service Provider AgID	Tu	Noi (white-label)
Generazione metadata	Tu, con la libreria	Noi, pannello
Rotazione certificati X.509	Tu, scadono ogni 2 anni	Noi, automatico
Replay cache	Tu, su Redis tuo	Noi, su nostro cluster
Onboarding nuovi IdP	Tu, con release tua	Noi, trasparente
Aggiornamento Linee Guida AgID	Tu, attendi PR community	Noi, automatico
Log audit-ready 24 mesi	Tu, infrastruttura tua	Noi, pannello
Single sign-on cross-domain	Da implementare	Out-of-the-box

Il pattern di compatibilità (proxy IdP unificato)

Per chi ha un'integrazione esistente con una libreria SPID PHP e non vuole riscrivere niente, abbiamo sviluppato un pattern di compatibilità: il nostro service espone un endpoint che, dal punto di vista del tuo software, sembra ancora un IdP «diretto». Tu non cambi codice, cambia solo l'entityID che la tua libreria chiama.

// Prima: config della tua libreria SPID open
$config = [
  'idp' => [
    'poste' => 'https://posteid.poste.it',
    'infocert' => 'https://identity.infocert.it',
    // ...
  ],
];

// Dopo (con il proxy IngressoDigitale): un solo IdP «logico»
$config = [
  'idp' => [
    'ingressodigitale' => 'https://proxy.ingressodigitale.com/sp/REGISTRY/idp.xml',
  ],
];

IngressoDigitale dietro le quinte gestisce la federazione completa con tutti gli IdP SPID e CIE. Tu non vedi più la lista, vedi un endpoint solo.

Profilo di migrazione tipo

Un cliente tipo che gestisce il portale di un ente con qualche migliaio di iscritti, partito anni fa con una libreria SPID PHP custom, oggi si trova con:

Server Linux dedicato, PHP 7.4 o 8.x, libreria SPID con manutenzione altalenante
Certificati X.509 rinnovati a mano ogni due anni con downtime di alcune ore per ogni rinnovo
Replay cache su SQL (lento) anziché Redis
Periodi di non-conformità quando AgID rilascia nuove Linee Guida e la PR community arriva in ritardo

Un percorso di migrazione tipico a IngressoDigitale richiede:

Settimana 1: assessment, creazione SP su IngressoDigitale, generazione metadata di test
Settimana 2: integrazione SDK PHP IngressoDigitale a fianco della libreria esistente (coesistenza)
Settimana 3: test parallelo, smoke test su 9 IdP demo
Settimana 4: switch traffico 50/50, poi 100% su IngressoDigitale

Risultati attesi dopo 12 mesi su un profilo di traffico medio:

Ticket sicurezza interni: forte riduzione (anche oltre l'80% nei casi che abbiamo seguito)
Tempo per gestire rinnovo certificati: zero (era una settimana ogni due anni)
Conformità Linee Guida AgID: sempre allineata
La software house libera risorse interne per dedicarsi al core del proprio prodotto

FAQ migrazione

Devo riscrivere tutto il mio codice?

No. L'SDK IngressoDigitale può convivere con la tua libreria SPID PHP esistente per tutto il tempo che serve. In molti casi si tocca solo la pagina di callback per accettare anche il token IngressoDigitale.

Cosa succede agli utenti già loggati con sessione attiva?

Niente, le sessioni applicative restano. Cambia solo il prossimo login: l'utente sceglie SPID e arriva di nuovo nel tuo software, senza differenze percepite.

Il mio entityID cambia?

Sì. Avviserai AgID con una semplice comunicazione (te la prepariamo noi). Per il cittadino il cambio è trasparente.

Quanto tempo è realistico?

Per progetti standard 3-6 settimane. Per progetti con molte personalizzazioni custom o requisiti SLA particolari, 6-10 settimane.

Stai pensando di migrare?

Un'analisi tecnica gratuita del tuo setup attuale. In 1 ora ti diciamo dove stai e dove puoi arrivare.

Richiedi una demo Come funziona