Ciao a tutti,
stiamo cercando di inviare il metadata di federazione in CIE in ambiente di preproduzione/collaudo.
Ogni volta appare il seguente avviso:
- [/EntityDescriptor/Signature/KeyInfo/X509Data/X509Certificate] Certificato non valido
Ho utilizzato una libreria che genera automaticamente il metadata e per SPID non ho avuto alcun problema. Sicuramente non sto rispettando qualche requisito di soddisfacibilità, ma l’errore che appare non mi aiuta.
Qualcuno ha avuto il mio stesso problema?
Un caro saluto.
Con non poca fatica sono riuscito a farmi accettare il metadata. Il motivo per il quale la piattaforma mi respingeva il metadata di preproduzione/collaudo è che il digest presente nel metadata differiva dal digest della firma del metadata. Utilizzando la libreria “italia/spid-php”, con il comando:
composer sign-metadata <metadata.xml> <metadata-signed.xml>
andavo a ri-firmare il metadata generato dalla libreria stessa dopo le opportune modifiche fatte al file xml. Per qualche motivo questo non ha funzionato per me. Utilizzando un altro servizio il metadata di collaudo (e anche quello di produzione) mi è stato accettato correttamente.
Spero di essere stato esauriente nella spiegazione del problema e della sua risoluzione.
Saluti
Buon pomeriggio Mattia, scusa se appofitto del tuo post per avere maggiori informazioni in merito ai metadati di Federazione come SP.
Sto impazzendo nella configurazione del WSO2 e nella produzione del file XML dei metadati.
Che libreria hai usato per farti creare il file XML? Hai modo di condividere (depurato delle informazioni “personali”) il file XML che sei riuscito a produrre?
Grazie anticipatamente
Saluti
Buon pomeriggio @Italo_Gazzaneo ,
la libreria che ho utilizzato per integrare l’accesso ai servizi e per la generazione del metadata di federazione è “italia/spid-php” (GitHub - italia/spid-php: Software Development Kit for easy SPID access integration with simplesamlphp). Il nome della libreria potrebbe ingannare: da poco è stata aggiunta l’integrazione per CIE e con qualche problema ha funzionato per me.
Puoi clonare la libreria attraverso il comando:
git clone https://github.com/italia/spid-php
Poi, per poter procedere all’installazione, lancia il comando:
composer install
Partirà lo script che chiederà l’inserimento dei dati per la generazione del metadata e delle relative chiavi (chiave privata e certificato). Una volta terminato il processo di installazione, troverai il metadata al seguente percorso:
/myservice/module.php/saml/sp/metadata.php/cie
dove myservice è il nome del servizio come specificato durante l’installazione.
Una volta ottenuto il metadata di federazione, puoi caricarlo sulla piattaforma di onboarding https://federazione.servizicie.interno.gov.it/
Spero che la mia risposta sia stata esaustiva.
Saluti
Ciao @mattiapassaseo, innanzitutto grazie per la risposta.
Ho seguito la procedura ma dopo il “composer install” non parte lo script automatico che consente l’inserimento dei vari dati per la generazione dei metadata.
Probabilmente è un problema della mia installazione.
Sto usando Ubuntu tramite WSL.
Buona sera @Italo_Gazzaneo ,
due possibili motivi per il quale non ti parte lo script potrebbero essere:
- Verifica se composer è installato. È sufficiente lanciare il comando
composer --version
- La libreria richiede requisiti minimi visibili nel file composer.json come ad esempio la versione di php, openssl ecc… Verifica di possedere tutti i requisiti prima di lanciare lo script.
Saluti
Buongiorno Mattia, sono arrivato finalmente ad avere un file dei metadata correttamente compilato ma ho lo stesso tuo problema iniziale.
- [/EntityDescriptor/Signature/KeyInfo/X509Data/X509Certificate] Certificato non valido
Come lo hai risolto? Io il file l’ho generato da una mia macchina locale su cui ho fatto l’installazione e non sulla macchina che ospita il WSO2 che si occuperà di fare da SP.
Puoi darmi qualche dritta?
Grazie
Buongiorno @Italo_Gazzaneo ,
il problema sotto all’errore “Certificato non valido” è che il digest presente nel metadata differisce dal digest della firma del metadata stesso. Sul mio sistema, il comando composer sign-metadata di spid-php, non ha funzionato.
Ho utilizzato uno strumento esterno (Online XML SAML Metadata Signing Tool | SAMLTool.com) dandogli in pasto: il metadata generato senza il tag <ds:Signature>…</ds:Signature>; la chiave privata e il certificato (che trovi nella cartella cert) scegliendo l’algoritmo rsa-sha256. A quel punto basterà prendere il nuovo metadata generato e ricaricarlo sulla piattaforma di onboarding. In questa maniera dovresti aver risolto il problema.
Saluti
Grazie @mattiapassaseo sono riuscito a produrre finalmente il file dei metadata.
Ti chiedo solo qualche altra info, come hai proseguito con i test vs CIE di preproduzione? che cosa hai installato per provare a far dialogare il tuo ambiente di sviluppo con CIE?
Io sto cercando di configurare il nostro WSO2 per farlo dialogare con CIE…ma senza successo.
Buonasera @Italo_Gazzaneo ,
mi fa piacere che tu sia riuscito ad ottenere correttamente il tuo metadata di preproduzione CIE.
Una volta inviato il file metadata sulla piattaforma di onboarding lo stato della pratica passerà in “Ambiente di preproduzione verificato”. A questo punto, potrai effettuare i test tramite la stessa liberia con la quale hai generato il file metadata. spid-php è già predisposta all’integrazione dell’accesso con CIE. Se lo hai indicato nella configurazione iniziale, lo script dovrebbe aver creato un file login.php per testare il tutto. Una volta effettuati i test e modificato il relativo metadata se necessario, potrai caricare il metadata di produzione finale con la quale completare il processo di federazione con CIE.
Saluti
Buonasera @mattiapassaseo perdonami se torno a disturbarti e ad approfittare delle tua pazienza.
Ho concluso il processo di federazione e l’accesso con i dati federati funziona correttamente usando simplesamlphp.
Ora un’altra esigenza che è quella di usare WSO2 per Identity Server e far passare tutte le richieste tramite un IdP configurato su WSO2.
Fin qui diciamo tutto ok.
Il client (applicazione X) chiama WSO2 che lo identifica e lo gira al IdP opportunamente configurato e che risponde al server CIE di preprod.
Ottengo però la risposta: “La richiesta non può essere soddisfatta poiché il messaggio ricevuto non rispetta i requisiti di sicurezza del servizio di accesso.”
Confrontando la richiesta generata da SimplesamlPhp e quella di WSO2 non ho notato differenze se non quelle del certificato.
Ipotizzo possa dipendere dal mancato riconoscimento del certificato e mi chiedo.
Nel file metadata inviato a CIE l’ho firmato con i due certificati presenti in “cert” e relativi al sistema CIE…ho sbagliato questa procedura?
Cordialmente
Ciao @Italo_Gazzaneo ,
rispondo anzitutto alla tua domanda: no, non hai sbagliato la procedura. Il metadata va firmato con la chiave privata e il certificato presenti all’interno della directory “cert”, generate in fase di installazione e configurazione della lib. Un’accortezza importante da avere è quella di non modificare il file una volta firmato perchè automaticamente la firma viene invalidata.
A titolo informativo ti riporto di seguito dei potenziali check da fare per poter risolvere il tuo problema, presenti nel manuale tecnico CIE.
«La richiesta non può essere soddisfatta poiché il messaggio ricevuto non rispetta i requisiti di sicurezza del servizio di accesso.» Potenziale problema sui sigilli elettronici (chiamati anche, impropriamente, «firme digitali») apposti sul metadata del SP stesso e/o sulle request. Occorre verificare:
- la presenza di un sigillo elettronico, nell’elemento
<Signature> in testa al metadata del SP, afferente al certificato elettronico di cui al punto successivo;
- la validità del certificato elettronico presente nell’elemento
<Signature> al punto precedente;
- la presenza, nella request, di un sigillo elettronico (afferente a uno dei certificati elettronici di cui al punto successivo) localizzato, alternativamente, nell’elemento
<Signature> della request, nel caso di binding in HTTP POST, ovvero nel parametro Signature della query string veicolante la request, nel caso di binding HTTP Redirect;
- la validitá del certificato elettronico afferente al sigillo di cui al punto precedente; tale certificato, all’interno del metadata del SP, si trova tra gli elementi
KeyDescriptor con l’attributo use valorizzato con signing;
- la coerenza dell’attributo
Destination nella request con l’attributo Location del tag SingleSignOnService riportato nel metadata dell’IdP in relazione al tipo di binding utilizzato per inviare la request.
Saluti