menu di navigazione del network

AuthnRequest signature validation FAIL

Salve a tutti,
la mia azienda sta provando ad accreditarsi come SP privato per poter fornire l’accesso tramite SPID ai nostri utenti.

Come consigliato, abbiamo scaricato lo spid-saml-check (GitHub - italia/spid-saml-check: Tool di verifica implementazione SPID SAML) per effettuare le varie verifiche su metadata, request e response.

Purtroppo abbiamo un errore che non riusciamo a risolvere sulla validazione della request, in particolare l’ultimo punto dei test della categoria “Check Strict” :

[FAIL] The AuthnRequest must validate against XSD and must have a valid signature
stdout: Validating XSD... OK
stdout: Validating signature... FAIL
stderr: /tmp/tmp.j1daWwrsIW validates
stderr: dgst: Unrecognized flag <NULL>
stderr: dgst: Use -help for summary.

E’ evidente che sia un errore con la signature della request ma non abbiamo molte informazioni per capire dove sia il problema.
Inoltre, validando la request con questo tool Validate SAML AuthN Request Online Tool | SAMLTool.com NON vengono segnalati errori.

Potreste aiutarci a capire come sistemare?

Grazie mille

Buongiorno, sto eseguendo anche io i test con spid-saml-check, anche io con l’errore “[FAIL] The AuthnRequest must validate against XSD and must have a valid signature”.

Andando a controllare la finestra di esecuzione di docker, prima di questo errore mi viene segnalato “[FAIL] The Destination attribute must be a valid HTTPS url - TR pag. 8” (errore corretto dato che la macchina docker con il tool di validazione utilizza HTTP al posto di HTTPS).

Purtroppo non ho trovato informazioni su come attivare il protocollo HTTPS sull’immagine Docker, ma ho fatto il test seguendo questo post (su spid-saml-check con dominio esterno e HTTPS): Servizio SPID Validator disponibile pubblicamente su spid-validator.it

Ciao Andrea,
anche io avevo quell’errore nei test in locale ma il giro funzionava e ho potuto fare i vari test.
Poi una volta configurato l’indirizzo con https si sistemerà il test.

Nel mio caso specifico docker mi dà un errore sulla firma della request, dicendo che “il digest non matcha col data” quindi ho provato a rigenerare il certificato e a firmare nuovamente il metadata ma ottengo sempre lo stesso errore.

Ho provato anche con un certificato che usiamo per un altro applicativo, ma neanche quello risolve.

La cosa strana è che usando il tool di validazione che ho citato nel primo post non ho errori, quindi non so proprio dove intervenire

Ciao,
anche io ho riscontrato lo stesso errore utilizzando lo spid-saml-check (sia con versioni vecchie, sia con l’ultima versione scaricata e installata il 26 Luglio 2021 localmente sul mio PC su docker) nella validazione delle request:
The AuthnRequest must validate against XSD and must have a valid signature stderr: ./script/check-request-xsd-and-signature.sh: line 17: $’\r’: command not found stderr: ./script/check-request-xsd-and-signature.sh: line 19: $’\r’: command not found stderr: ./script/check-request-xsd-and-signature.sh: line 22: $’\r’: command not found stderr: ./script/check-request-xsd-and-signature.sh: line 25: $’\r’: command not found stderr: cat: ‘./data/https___paghepa_alma_spa_it’$’\r’’/SAMLRequest.authn’$’\r’’.request.txt’: No such file or directory stderr: ./script/check-request-xsd-and-signature.sh: line 70: syntax error near unexpected token elif' stderr: ./script/check-request-xsd-and-signature.sh: line 70: elif [ “${CTX}” == “logout” ]; then ’

Confermo che nonostante ciò il metadata è stato validato senza problemi e l’AGID mi ha inviato il certificato ufficiale con cui ri-firmare il metadata sostituendo il certificato autofirmato prima prodotto.
Ho quindi firmato il metadata con il nuovo certificato e eseguito i test con lo SPID-validator riscontrando, come già detto, solo l’errore sopra indicato.

Ora però voglio rieseguire alcuni test di autenticazione tra il mio SP e un IDP di prova:
non ho più utilizzato il spid-testenv2, in quanto non funziona più con l’ultima versione di docker ed è a fine ciclo di vita, e quindi devo utilizzare lo spid-saml-check, che nell’ultima versione integra anche un IDP di test.
In questo IDP di test però, viene eseguita una validazione della request prima dell’autenticazione e purtroppo l’errore indicato precedentemente è bloccante e mi è impossibile quindi proseguire nei test.

Potete risolvere il problema?

E’ inoltre possibile inserire utenti personalizzati nello spid-saml-check?

Grazie,
Davide

Ciao Davide, nella parte delle regole tecniche relativa all’AuthnRequest si afferma che:

  • nel caso del binding HTTP POST deve essere presente l’elemento <Signature> contenente la firma sulla richiesta apposta dal Service Provider. La firma deve essere prodotta secondo il profilo specificato per SAML (SAML-Core, cap. 5) utilizzando chiavi RSA almeno a 2048 bit e algoritmo di digest SHA-256 o superiore.

L’errore evidenziato dovrebbere dipendere da uno o più dei seguenti casi:

  1. Hai inviato una AuthnRequest con Binding HTTP - POST priva di firma (tag Signature).

  2. La firma non rispetta i parametri indicati sopra.

  3. La firma non combacia con nessuno dei certificati presenti nel metadata (tag KeyDescriptor)

  4. Il digest della firma non combacia con il contenuto della AuthnRequest

Grazie @AGS ,
in riguardo ai primi 3 punti tutto ok, ma come faccio a sapere se il digest della firma è ok?

Ho provato alcuni tool online per generare il digest dalla firma e non ottengo un digest uguale a quello presente nella mia authnRequest, ma non sono sicuro di aver fatto le cose giuste…

Ad esempio su https://8gwifi.org/MessageDigest.jsp, dopo aver selezioanto sha256 ho incollato la firma
B1mklC/58WFpRZQRg3cTXU9mRMi5aRIo6/o4E+nd1zaw29L0U6AbVpRN2rdTVvVGm92IkokgX+JA+Jw9z2JPfN4umIAFNsI0mEp1MHX3TuNnTuzGhkQ/0uHlLn/SSZnzaZLbhKjEzS+vpBup/WVFIy2O6xjEdLMG7MC9eKnC92ESIncdwbgNFOLEEUTM1liUHXvz9tMD57lbF6t3aSzGD/igOmwQ5pJYN9RtZAUqXwWn85UeGCZCNdyghxN3DDcXSwuUz8ppdr6SDi01ATdng4R6x8nnYp1fKbVRmbHiA+v8LnRBGJMqpB8NOFzn2GO+R4mM/khqGYX2lNG0lfeU0A==

ma ottengo un digest
HzZhQgNFrTkhrykmG6IBKuLps/4HhgSoM00OaPTXaY0=
diverso da quello presente nella request
jhUbHlPDfkotoe2d16h019MXtsb7t9gbpGsEJ/GEjKo=

Ho fatto la stesso cosa con altri esempi di authnrequest trovati nella documentazione online e il digest è comunque diverso. Sbaglio qualcosa?

Questa è la mia request:

<?xml version="1.0" encoding="UTF-8"?>
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" AssertionConsumerServiceIndex="0" AttributeConsumingServiceIndex="1" Destination="https://174.174.174.94:8080/samlsso" ForceAuthn="true" ID="_3a7777cd-46f3-466f-bd8f-434e6d4366ed" IssueInstant="2021-07-27T09:49:16.609Z" Version="2.0">
    <saml2:Issuer xmlns:saml2="urn:oasis:names:tc:SAML:2.0:assertion" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity" NameQualifier="https://paghepa.alma-spa.it">
        https://paghepa.alma-spa.it
    </saml2:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#_3a7777cd-46f3-466f-bd8f-434e6d4366ed">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    jhUbHlPDfkotoe2d16h019MXtsb7t9gbpGsEJ/GEjKo=
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
            B1mklC/58WFpRZQRg3cTXU9mRMi5aRIo6/o4E+nd1zaw29L0U6AbVpRN2rdTVvVGm92IkokgX+JA+Jw9z2JPfN4umIAFNsI0mEp1MHX3TuNnTuzGhkQ/0uHlLn/SSZnzaZLbhKjEzS+vpBup/WVFIy2O6xjEdLMG7MC9eKnC92ESIncdwbgNFOLEEUTM1liUHXvz9tMD57lbF6t3aSzGD/igOmwQ5pJYN9RtZAUqXwWn85UeGCZCNdyghxN3DDcXSwuUz8ppdr6SDi01ATdng4R6x8nnYp1fKbVRmbHiA+v8LnRBGJMqpB8NOFzn2GO+R4mM/khqGYX2lNG0lfeU0A==
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:KeyValue>
                <ds:RSAKeyValue>
                    <ds:Modulus>
                        zAfQ3Hi3tnQd9iz/qGz4zl5YZxbc59AwQAKF5gRswOltY34vBuI6RuM9stshFB2rnVMtKHh4EDou
uEaa73A5VqtrPnIZws56Zy5wkDzDskrSzqeqmK9fSCFvqL/5c+EE2VDNMLBGmV6mC/UNA+qIFY7/
LetE73yNzh4ospvfuEq9JLA2x8Sw09bBHS2SrfT/CvRPpAgcdONEaS1BPz6EeITMTb7nVUklxT+3
4yyJmH/54I3m2Bb+R4ZAq18Jy99kSyjBHAE/ms86Q0lEQ3SpsFpHjo/SVVIPp3/zet0zyBz7v4Pw
I/Lb2wVkL4BTSsAw5e3NDcSBvHAuKiu0MDM/fQ==
                    </ds:Modulus>
                    <ds:Exponent>
                        AQAB
                    </ds:Exponent>
                </ds:RSAKeyValue>
            </ds:KeyValue>
            <ds:X509Data>
                <ds:X509Certificate>
                    MIIIIzCCBgugAwIBAgIIARlR2HSoFqcwDQYJKoZIhvcNAQENBQAwgegxCzAJBgNVBAYTAklUMQ0w
CwYDVQQHDARSb21lMSYwJAYDVQQKDB1BZ2VuemlhIHBlciBsJ0l0YWxpYSBEaWdpdGFsZTEwMC4G
A1UECwwnU2Vydml6aW8gQWNjcmVkaXRhbWVudG8gZSBwcm9nZXR0byBTUElEMSkwJwYDVQQDDCBQ
cm9nZXR0byBTUElEIC0gU29nZ2V0dGkgcHJpdmF0aTEpMCcGCSqGSIb3DQEJARYacHJvdG9jb2xs
b0BwZWMuYWdpZC5nb3YuaXQxGjAYBgNVBAUTEVZBVElULTk3NzM1MDIwNTg0MB4XDTIxMDcxNTAw
MDAwMFoXDTM2MDcxNDIzNTk1OVowgc8xHDAaBgNVBAMME0FsbWEgQ2VudHJvIFNlcnZpemkxCzAJ
BgNVBAYTAklUMRswGQYDVQQHDBJWaWxsYW5vdmEgTW9uZG92w6wxCzAJBgNVBAgMAkNOMRQwEgYD
VQQKDAtBbG1hIFMucC5BLjEaMBgGA1UEYQwRVkFUSVQtMDA1NzIyOTAwNDcxJDAiBgNVBFMMG2h0
dHBzOi8vcGFnaGVwYS5hbG1hLXNwYS5pdDEgMB4GCSqGSIb3DQEJARYRcG9zdGFAYWxtYS1zcGEu
aXQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDMB9DceLe2dB32LP+obPjOXlhnFtzn
0DBAAoXmBGzA6W1jfi8G4jpG4z2y2yEUHaudUy0oeHgQOi64RprvcDlWq2s+chnCznpnLnCQPMOy
StLOp6qYr19IIW+ov/lz4QTZUM0wsEaZXqYL9Q0D6ogVjv8t60TvfI3OHiiym9+4Sr0ksDbHxLDT
1sEdLZKt9P8K9E+kCBx040RpLUE/PoR4hMxNvudVSSXFP7fjLImYf/ngjebYFv5HhkCrXwnL32RL
KMEcAT+azzpDSURDdKmwWkeOj9JVUg+nf/N63TPIHPu/g/Aj8tvbBWQvgFNKwDDl7c0NxIG8cC4q
K7QwMz99AgMBAAGjggLmMIIC4jAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBSQmj6H3o5Pr/dOdjPh
FBx4+RZ7gDAfBgNVHSMEGDAWgBScRTDETQ+g+iYPqdb8INYHbM5kVjAOBgNVHQ8BAf8EBAMCBsAw
FgYDVR0SBA8wDYILc3BpZC5nb3YuaXQwQwYDVR0fBDwwOjA4oDagNIYyaHR0cHM6Ly9laWRhcy5h
Z2lkLmdvdi5pdC9jcmwvY3JsX1NQSURfcHJpdl9TQS5jcmwwNwYIKwYBBQUHAQEEKzApMCcGCCsG
AQUFBzABhhtodHRwczovL29jc3BfU0EuYWdpZC5nb3YuaXQwggHXBgNVHSAEggHOMIIByjAJBgcE
AI5GAQYCMIGVBgQrTBAGMIGMMEQGCCsGAQUFBwICMDgaNkVsZWN0cm9uaWMgY2VydGlmaWNhdGUg
Y29uZm9ybWluZyB3aXRoIEFHSUQgR3VpZGVsaW5lczBEBggrBgEFBQcCAjA4GjZDZXJ0aWZpY2F0
byBlbGV0dHJvbmljbyBjb25mb3JtZSBhbGxlIExpbmVlIGd1aWRhIEFnSUQwewYGK0wQBAMBMHEw
NQYIKwYBBQUHAgIwKRonU1BJRDogZm9ybml0b3JlIGRpIHNlcnZpemkgKFNQKSBwcml2YXRvMDgG
CCsGAQUFBwICMCwaKlNQSUQ6IHByaXZhdGUtc2VjdG9yIFNlcnZpY2UgUHJvdmlkZXIgKFNQKTAI
BgYEAI96AQMwTQYEK0wQBDBFMEMGCCsGAQUFBwIBFjdodHRwczovL2VpZGFzLmFnaWQuZ292Lml0
L2Nwcy9BZ0lEX2VJREFTX3Jvb3RDQV9jcHMucGRmME8GBgQAjkYBBTBFMEMGCCsGAQUFBwIBFjdo
dHRwczovL2VpZGFzLmFnaWQuZ292Lml0L2Nwcy9BZ0lEX2VJREFTX3Jvb3RDQV9jcHMucGRmMBEG
CWCGSAGG+EIBAQQEAwIABzANBgkqhkiG9w0BAQ0FAAOCAgEAeKrSVRZwTA89YGLq2Brat+KhNSGy
yW92Ty1naZEY6wbGZy5hJ3t34XQfyf9fwWmTneuJhRgwd0BY17pAbJxRP1qMtHBa4xuxH9S3qxQZ
SYd72oY8sIeuxvgrW/18AtCJliYFF45r0OhhhJLQncketP1oFnQH19ImFuxPQGEEk7NKKt4jGxDs
vximNucnvTeFAvjHpKOEDn+rao6koGdXVfQ6jP3j94YNrUlK7Qg2awxJd3LhDVpcXVQZUSGGvEnD
oVtdfNjV/esD2r8cA58x95tcPgx/tBtJnB9A9I4ggEbrQK9iVaOsDPjvN9EJqnO9iLqje5RzXkla
oHi2lCws0Jfp4tj/vNHgbQtOKdnlmN2fh0MrizLHZjBcQEju0Rc585LoazafNpp6vocs/WfD6tKp
Z5HxXWc+ZyKlAMD5aTnPvlAd5wHLWPtwnrGTFe9NYH0Vqr//5+TZ0Q3shMQ8lxrFhCBeSotw7NwA
/ytvpDLqfRsAs6ODxMivs5mjrMfP/1JLfT0LTdtAhyrAALESSdoea2f9uiqsyu+d1w5QqpbpqeQ9
xRskmXzeHmWQzNfx61ayfZwH93ZanrOv/iizNljILfrCwdWTwjhdpg/H9PwojWPRC2r42kn4o61O
5DfOVJmDNzOlc80YPNoaAuS7Uioj//H7LaATLoGiF+2wnwg=
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <saml2p:NameIDPolicy xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"/>
    <saml2p:RequestedAuthnContext xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" Comparison="minimum">
        <saml:AuthnContextClassRef xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
            https://www.spid.gov.it/SpidL1
        </saml:AuthnContextClassRef>
    </saml2p:RequestedAuthnContext>
</samlp:AuthnRequest>

In ogni caso l’errore originale dato dallo spid validator mi sembra un errore di esecuzione del codice, non una vera segnalazione di mancata validazione. Che ne dite?

Grazie,

Davide

Ciao Davide,

riguardando meglio gli errori da te riportati, ho notato questo messaggio:

Il file request.txt dovrebbe essere il file dove viene salvata temporaneamente la tua AuthnRequest per poi essere analizzata.
Sembra che il file in realtà non venga creato e che quindi l’errore derivi dal fatto che non esiste un’AuthnRequest da analizzare e quindi una firma da validare.

Può derivare dal fatto che il sistema non riceve la AuthnRequest, oppure per problemi di permessi in scrittura.

Ti segnalo che come alternativa a spid-saml-check puoi ustilizzare anche il tool spid-sp-test.

Grazie @AGS ,
l’errore quindi è del codice del spid-saml-check e non ci posso fare nulla…

A chi posso segnalarlo?

Davide

Apri una issue sul repository github del progetto.

Fatto…

https://github.com/italia/spid-saml-check/issues/163