ERRORE 403

[DATASOFTNA]

Buongiorno, chiedo scusa se la richiesta non e' formattata nei migliore dei modi, ma devo ancora capire bene come funziona questo coso.

Dopo avere preparato tokens auth e firma sintatticamente corretti, alla richiesta di validazione di un PDF, ottengo sistematicamente l'errore "403 AuthorizationContantDeny", anche dopo avere fatto vari tentantativi variando qualche parametro di autenticazione nei token jwt. Ecco di seguito tutti i token coinvolti, il comando e l'esito della chiamata Head auth auth_head.txt Payload auth auth_payload.txt Head firma firma_head.txt Head payload firma_payload.txt Comando con esito comando.txt

Potreste dirmi da cosa e' causato il rigetto della richiesta ?

Vorrei inoltre fare presente che nella documentazione sono riportati alcuni esempi di chiamata con curl che cosi' come sono scritti, non hanno nessuna possibilita' di funzionare; sarebbe auspicabile avvisare che sono solo fittizi o proporre degli esempi corretti in quanto sarebbero molto utili per una simulazione veloce. Grazie per l'attenzione.

[ponsilva]

Buongiorno, condivido un'info dato che anch'io ho eseguito un po' di chiamate al gateway con curl.

Il certificato da mettere in --cert è quello di autenticazione _auth

Il certificato signature _sign viene utilizzato unicamente per la firma dei token JWT

[DATASOFTNA]

Grazie per la celere risposta. Ho fatto la prova utilizzando nella chiamata curl i parametri relativi ad AUTH, ma la risposta e' la stessa (il trace e' identico al precedente)

Ho fatto anche un tentativo firmando il token auth con la chiave privata AUTH e adesso la risposta che ottengo e' 400 "....the request is not conform to the required interoperability profile" Posso considerare che la fase di autenticazione sia passata e che il problema sia da qualche altra parte ?

In questo caso, quale potrebbe essere il problema ? In allegato ci sono i token e la risposta auth_sign.txt

[DATASOFTNA]

E' il caso di aprire un altro topic o posso continuare su questo ?

[DATASOFTNA]

La documentazione dichiara

Entrambi i token devono essere firmati utilizzando il certificato “signature”.

Devo dedurre che firmare il token auth con la chiave firma_privata del certificato auth non sia corretto ? Pero' se firmo il token con la chiave firma_privata del certificato sign, ottengo forbidden con errore 403.

[masciamariotti]

Buonasera, potrebbe verificare che sta utilizzando i certificati p12 generati a partire dai pem ricevuti via email? La rimandiamo a questo link su Slack, in cui sono stati spiegati gli step passo passo. Se dovesse ancora riscontrare errore, le chiediamo gentilmente di riportare in questo thread la risposta ricevuta comprensiva di govway-id.

[DATASOFTNA]

La rimandiamo a questo link su Slack, in cui sono stati spiegati gli step passo passo.

Ehmm, ho clickato sul link e mi sono trovato davanti a numerose pagine piene di "interlocuzioni" nelle quali mi sembra difficile trovare quello che cerco (mi viene il dubbio di avere sbagliato a navigare). Comunque per quanto riguarda i certificati, si' sono in formato p12, ma continuo a ricevere l'esito 403. Le allego i token, il comando, l'esito ed il trace dal lato client sperando possa essere utile per capire dove sia il problema. Grazie per l'attenzione. P.s. Potrebbe essere utile sapere se c'e' qualche utente che sta utilizzando con successo curl per interagire con il gateway.Dovrebbe essere legale, visto che nella documentazione e' citato piu' volte. esito_err.txt

[masciamariotti]

Potrebbe verificare se ha allegato i JWT corretti? Effettuando il decode tramite tool jwt.io notiamo che all'interno ci sono gli stessi campi, mentre per il FSE-JWT-Signature sono necessari un altro set di campi, che può trovare al link tabella 40. Le facciamo notare comunque che erroneamente nel Payload sta inserendo anche i campi alg / typ / x5c che invece devono essere presenti soltanto nella sezione header

[DATASOFTNA]

Ho eliminato i campi superflui e mi sono assicurato che i body dei due token siano diversi, ma l'effetto e' lo stesso. In allegato JWT AUTH JWT SIGN HEAD JWT AUTH decodificato JWT SIGN decodificato COMANDO TRACE ESITO

Dal trace si evince che i JWT trasmessi sono effettivamente quelli previsti e i campi del body JWT-FIRMA sembrano quelli attesi. esito2_err.txt

P.S. Al momento della richiesta di accreditamento ho dovuto definire vari parametri, tra i quali "common name del certificato di accesso" (CERT_DATASOFT), potrebbe avere qualche attinenza con la situazione attuale ?

[DATASOFTNA]

risult_stato.txt Ho effettuato la chiamata al servizio status ed e' andata a buon fine, cio' potrrebbe significare che il file p12 delle chiavi di autenticazione e' correttto. Da diverse prove effettuate con questo servizio e' risultato che Per invocare il servizio e' necessario solo il token AUTH Nel token AUTH i campi jti e sub sono opzionali Sembrerebbe quindi che il problema dell'errore 403 non dipenda dalle credenziali nel file p12, ne' dal token AUTH, dato che viene controllato e se non e' corretto il servizio risponde con l'errore 403 se il campo iss e' mancante o non correttamente valorizzato 400 se ognuno degli altri campi non e' correttamente valorizzato Quindi il problema della mia chiamata al servizio di verifica potrebbe dipendere dal PDF o dal TOKEN FIRMA, ma la diagnostica e' troppo ambigua per capire quale sia il colpevole. Forse l'ideale sarebbe testare un altro servizio che non necessiti del PDF in modo da isolare la casistica al TOKEN FIRMA. In allegato c'e' il log del test effettuato

Da altri test effettuati sul servizio verifica , l'errore che ottengo e' sempre 403 anche se vengono eliminati tutti i valori dei campi, tranne iss e sub dal token firma. Se invece vengono eliminati iss e sub , l'errore ottenuto e' claims not found, , da qui l'idea che siano i primi valori controllati prima di passare alla verifica sintattica e quindi il problema potrebbe essere nella loro valorizzazione. Tra parentesi, considerando che il campo sub puo' assumere qualsiasi valore lecito di codice fiscale, allora il problema dovrebbe risiedere nel valore del campo iss, pero' questo contrasterebbe con il fatto che nel token AUTH e' accettato. Trattandosi di pure ipotesi, spero in questa discussione di non avere introdotto elementi fuorvianti. Grazie per l'attenzione.

[IStacchiotti]

Buongiorno, abbiamo notato che nel token FSE-JWT-Signature, nel campo sub il codice fiscale all'inizio della stringa presenta un carattere in lower-case: "sub": "STNSVT59A14f839X^^^&2.16.840.1.113883.2.9.4.3.2&ISO"

Nel Bearer viceversa il campo risulta correttamente tutto in upper-case: "sub": "STNSVT59A14F839X^^^&2.16.840.1.113883.2.9.4.3.2&ISO"

Potrebbe verificare e correggere eventualmente il token FSE-JWT-Signature? Grazie

[DATASOFTNA]

Si', me ne sono gia' accordo prima, ed e' una prova che ho gia' fatto, il risultato e' sempre lo stesso. Ho anche fatto la prova con altri codici fiscali (corretti), sia con il codice PROVAX00X00X000Y (che mi sembra funzioni per altri utenti) Ecco i token relativi all'ultimo invio Non vorrei sembrare pedante, ma se il codice fiscale e' errato nel TOKEN, la diagnostica sarebbe auspicabile lo dicesse. esito_99.txt

[DATASOFTNA]

Il file allegato in precedenza riporta i nomi dei toke invertiti, ecco quello esatto esito_99.txt

[DATASOFTNA]

Spiacente, mi sono accorto che il campo attachment_hash era scritto in maniera errata. Corretto, rifatta la prova, stesso esito 964dc363-ee56-11ed-8882-005056ae54fa

[DATASOFTNA]

Nuovo tentativo, dato che mi sono accorto che nel token di firma DATASOFT in application_vendor non era tutto maiuscolo, stesso risultato allegato Anche la versione corretta da 3 a 3.0 esito_9x.txt

[IStacchiotti]

Buongiorno @DATASOFTNA, dalle analisi svolte ci risulta un errore nel parametro aud del token. Le chiediamo di correggerlo togliendo l'ultimo carattere "/".

• https://modipa-val.fse.salute.gov.it/govway/rest/in/FSE/gateway/v1/ (> AS IS)
• https://modipa-val.fse.salute.gov.it/govway/rest/in/FSE/gateway/v1 (> TO BE, come da documentazione)

Ci faccia sapere se l'errore persiste, grazie

[DATASOFTNA]

Grazie, l'errore e' proprio quello, adesso l'accesso e' consentito.

[IStacchiotti]

Buon pomeriggio, grazie per il feedback. La presente viene chiusa come risolta. Si può procedere con la riapertura nel caso fosse necessario ulteriore supporto. Grazie