[SPID] Errore durante test integrazione Keycloak con demo.spid.gov.it - Richiesta di supporto

Ciao a tutti,

sto cercando di integrare SPID con Keycloak in un progetto e mi sono arenata su un problema che proprio non riesco a risolvere. Spero che qualcuno di voi abbia già affrontato una situazione simile e possa darmi una mano.

La situazione: Ho configurato Keycloak su un server remoto e sto cercando di farlo funzionare come Service Provider per SPID. Fino a qui tutto normale, ho seguito la documentazione ufficiale e le varie guide che si trovano online.

Quello che ho fatto: Per prima cosa ho scaricato i metadata dal sito demo di SPID (https://demo.spid.gov.it/) e li ho personalizzati aggiungendo tutti i tag custom necessari per la compatibilità SPID. Dopo aver firmato digitalmente il metadata, l’ho validato usando il validator ufficiale su https://demo.spid.gov.it/validator con il Check Strict attivo - e qui tutto ok, nessun errore segnalato.

A questo punto ho configurato l’Identity Provider in Keycloak pensando di essere a posto, ma quando provo effettivamente a testare il flusso di login tramite https://demo.spid.gov.it/start, la cosa si blocca con un errore.

Il problema: Questo è il punto dove mi perdo. L’errore che vedo sulla GUI del demo non mi dà abbastanza informazioni per capire cosa stia andando storto. Ho anche installato l’estensione SAML Tracer su Chrome per dare un’occhiata alla SAML Request che viene generata, e sinceramente non vedo nulla di palesemente sbagliato.

La mia domanda: Cosa potrei essermi persa? Magari c’è qualche dettaglio specifico dell’integrazione Keycloak-SPID che non è ovvio dalle guide standard? Oppure ci sono errori tipici che il validator non intercetta ma che poi causano problemi nel flusso reale?

Ho il sospetto che sia qualche piccolo dettaglio di configurazione, perché tutto sembra funzionare “quasi” bene, ma quel “quasi” fa la differenza.

Se qualcuno ha esperienza con questa configurazione specifica o ha idee su dove andare a cercare, sarei davvero grata per qualsiasi suggerimento!

Grazie in anticipo,

Alessia

Buongiorno Alessia,

non mi torna quando scrivi:

Per prima cosa ho scaricato i metadata dal sito demo di SPID (https://demo.spid.gov.it/) e li ho personalizzati aggiungendo tutti i tag custom necessari per la compatibilità SPID.

Il metadata dell’ambiente demo (https://demo.spid.gov.it/metadata.xml) così come quello dell’ambiente validator (https://demo.spid.gov.it/validator/metadata.xml) sono metadata da IdP, infatti tali ambienti si comportano come Identity Provider nei confronti del Service Provider Keycloak.

L’eventuale modifica per la compatibilità SPID e la firma devono essere invece eseguite sul metadata da Service Provider, ovvero quello generato, nel nostro caso da Keycloak.

@damikael grazie per la risposta, sono il collega che con Alessia sta impazzendo su questa integrazione.
Partiamo dal presupposto che a marzo ero riuscito a fare un integrazione Keycloak SPID ma il cliente mi ha chiesto di aggiornare tutto all’ultima versione di Keycloak con una procedura più snella e quindi mi sono dovuto rimettere al lavoro dopo qualche mese di fermo (e quindi, nonostante il documento di specifiche creato, mi sono trovato a rifare tutto da zero o quasi).
Le procedure descritte sono forse state fraintese:
di fatto noi abbiamo usato il metadata di demo.spid.gov.it/ per creare l’IDP all’interno di Keycloak.
Una volta fatto questo abbiamo modificato le varie impostazioni necessarie (come il name in transient con attribute[name] fiscalNumber e altre) e fatto generare da keycloak il metadata SP.
A quel punto da questo metadata SP generato da keycloak abbiamo eliminato la parte di signature e abbiamo aggiunto i vari campi per rendere l’xml conforme a quanto richiesto dalla documentazione ufficiale.
Abbiamo aggiunto i campi di mapping e quelli dell’organization.
A quel punto abbiamo provveduto a firmare il tutto con certificato e chiave presente nel realm, per rimanere coerenti con la generazione dell’XML SP iniziale.
Passiamo questo file all’ambiente di validazione del sito e ci dà codice verde su tutti i campi.
Proviamo a quel punto a fare l’accesso con SPID e risulta quella pagina di errore che ha mostrato Alessia prima,

Buongiorno @Giuseppe_De_Luca , ora è più chiaro.
Provate a verificare la AuthnRequest, collegando l’IdP Validator tramite il metadata esposto alla url https://demo.spid.gov.it/validator/metadata.xml

Inviando una AuthnRequest all’IdP Validator, infatti, avrete modo di eseguire i check di validazione sulla request e capire qual’è il problema.

di fatto quindi rifacendo la procedura creazione IDP utilizzando /validator/metadata.xml e successivamente ricreando il metadata SP partendo da questo, esatto?

Esatto. Occorrerà poi validare nuovamente il metadata su SPID Validator

e infine inviare una AuthnRequest all’IdP Validator.

Ciao damikael,

grazie mille per il supporto e per averci aiutato a risolvere il problema principale di integrazione SPID-Keycloak sulla demo di SPID.

Adesso, dopo aver sistemato la questione iniziale, vorrei capire meglio come affrontare il problema dei check strict che risultano ancora in rosso nel validator ufficiale.

Ho notato che la request AuthnRequest che Keycloak genera non include gli attributi Format e NameQualifier nell’elemento <Issuer>, cosa che invece il validator SPID richiede tassativamente per superare i controlli strict. Questo è un limite noto di Keycloak che non inserisce questi attributi di default.

Mi chiedo quindi se la strada migliore sia davvero quella di deployare e usare il modulo spid-keycloak-provider presente su GitHub (https://github.com/italia/spid-keycloak-provider), che dovrebbe già gestire questa personalizzazione e garantire una maggiore conformità con le specifiche SPID.

Secondo te questa è la soluzione giusta per ottenere il full compliance? Oppure ci sono alternative o workaround che potrei valutare?

Ti ringrazio ancora per la tua disponibilità e ogni consiglio ulteriore sarà molto gradito!

Io suggerirei di utilizzare una soluzione pienamente conforme per l’implementazione del protocollo SAML personalizzato per SPID di tipo proxy integrabile verso Keycloak mediante standard OIDC.

Per php, è possibile utilizzare, ad esempio:
spid-cie-php come proxy
e spid-cie-php-oidc per l’integrazione del Proxy, come fosse un IdP, verso Keycloak su OIDC.

@damikael chiedo lumi:
Quindi praticamente usando un’installazione “pulita” di keycloak è impossibile avere una AuthnRequest conforme a quanto richiesto da SPID. E’ corretto?
Da quanto mi risulta, intercettando con SAML tracer la AuthnRequest, mi ritrovo una cosa del genere

<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
                    xmlns="urn:oasis:names:tc:SAML:2.0:assertion"
                    xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
                    AssertionConsumerServiceURL="https://slitest.duckdns.org/realms/slitest/broker/spid/endpoint"
                    AttributeConsumingServiceIndex="0"
                    Destination="https://demo.spid.gov.it/samlsso"
                    ForceAuthn="true"
                    ID="ID_d6f65d23-288c-431c-b4c2-df9946615bfe"
                    IssueInstant="2025-10-01T07:40:54.464Z"
                    ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
                    Version="2.0"
                    >
    <saml:Issuer>https://slitest.duckdns.org/realms/slitest</saml:Issuer>
    <dsig:Signature xmlns:dsig="http://www.w3.org/2000/09/xmldsig#">
        <dsig:SignedInfo>
            <dsig:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <dsig:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" />
            <dsig:Reference URI="#ID_d6f65d23-288c-431c-b4c2-df9946615bfe">
                <dsig:Transforms>
                    <dsig:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <dsig:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
                </dsig:Transforms>
                <dsig:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />
                <dsig:DigestValue>zLPOYth2+WsYghiSVigMLwtyrHLAsr0WdKdt1Pla3Zo=</dsig:DigestValue>
            </dsig:Reference>
        </dsig:SignedInfo>
        <dsig:SignatureValue>PVqu3DD4lN5iQdbFLS/yDv2lb7LLa+JY67eOH4KvMoyL7lDyboR+7QMk4vMJjJksUPUBPZASnJPdu71o2rguBH+NpAx6fxJjU+zZwZWVnoIEOXbG9FP2p1jC96AyUzOd/qtNachs6esLL38TfZl4XYBb3h9wEvPjNsjpe+ZMGOqU5nHq3H1RziqyPcZm5LPg4wPXB8w2jTrDVEC7MTwjvj3FG1RVkKLixULB7UFUTLhM7kaNNx8PmUDDn9fY0ZRMBaP/jEyUf16gphpU4hSKRWVh79PdkA5PFHaqlUJYESErZ7lk9PRSYyg3d6fQ02Jc4D1Wj9SP+KyOfkDGiIgcRQ==</dsig:SignatureValue>
        <dsig:KeyInfo>
            <dsig:X509Data>
                <dsig:X509Certificate>MIICqzCCAZMCFFz2ywPk24BtrK5Eu3VcEVCLS22BMA0GCSqGSIb3DQEBCwUAMBIxEDAOBgNVBAMMB3NsaXRlc3QwHhcNMjUwOTAyMTUxNjQ5WhcNMjYwOTAyMTUxNjQ5WjASMRAwDgYDVQQDDAdzbGl0ZXN0MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA1OhlyKVRGAvHWocSlQ5dApfYA0u/RM0VBEq6rGfBOnU1948uzDP0Th+3oIX+oa/XYA7zVgrsxbAife9wmvXxlaECC6bfNB4wk/usn2lfflTuF8Rvmz1vxA9TaJolvwjvwTtUO+l51C+OnzT5jFtSgK4Y9zjZkF0jaclFxcaIrHaAh7KIDkEMC5LNF+Xwf9h2F3WIrYrOoLjQ0jOEiQE60DSl4PgKyt4vv64XnDiVg2exb9GcfpEr7EBmgmZIolVfhj6kiMQ8VRQJ2CuCkS1UgO68okEZoFK240NqAtFyOYfNzpb8uPsBIxQdzjZxoz7Ky1mhGg4+AsmpZ7xej8eksQIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQCq4TqmmwVCbfoW9srIztICcH99DyW7H8KpwQQhEvnu7jD0UwqDc3sPz7DNiTa16xWN8HsIzIqdSkXlqFlhhhToh6Xnbj5nRDX05cYG24Ta/Yv56itjBw4vkTBPSSwC19wd50p8Jd7fOLb7911cDSFGTAWVUqY1BTXzfQ0GXN20Na2ZuI+u0T59WM7ryFO6PRrlRnGTemJICc0HvtPX4EIHlTraNCmUnLMqv+7FlEcaSG+Yevez3g6Be/viqJxajboX4HO0pdLLUpBzU2sC/242ZZs0CoXsV836WT0lUmyu7cNZ+cPY3vY33e0UwE4pNjmloE/5iYE6aM4ENimoNV0p</dsig:X509Certificate>
            </dsig:X509Data>
        </dsig:KeyInfo>
    </dsig:Signature>
    <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient" />
    <samlp:RequestedAuthnContext Comparison="minimum">
        <saml:AuthnContextClassRef>https://www.spid.gov.it/SpidL1</saml:AuthnContextClassRef>
    </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>

e quindi mancano degli attribute, da documentazione, su issuer e nameIDPolicy

Buongiorno @Giuseppe_De_Luca ,

SPID inserisce diverse personalizzazioni al protocollo standard SAML, attraverso le Regole Tecniche ma anche tramite gli Avvisi pubblicati da AgID, vedi ad esempio l’Avviso n.29 v.3, o l’Avviso n.19 v.4 per Aggregatori, che specificano, ad esempio, la necessità dell’elemento Organization nel metadata, oppure i valori dei campi dei certificati validi da utilizzare per la firma delle AuthnRequest.
Tutte queste specifiche non sono di base presenti in implementazioni standard SAML ed è necessario pertanto utilizzare configurazioni specifiche o plugin, ove disponibili, che recepiscono tutte le ulteriori specifiche SPID.

creando una custom image di keycloak, integrando il progetto spid provider che troviamo su github, queste restrizioni sull’authnrequest vengono superate?
Anche se pero’ ho già provato ad installare il plugin nell’ultima versione di Keycloak (26.3.3) ma mi sta dando qualche problema nella build.

Mi spiace, ma non conosco bene il progetto spid per keycloak cui ti riferisci, quindi non ti so dire se è pienamente conforme alle ultime specifiche.