Open rangemasterd opened 1 month ago
Buongiorno, dalle analisi effettutate sui log della chiamata da lei riportata, è emerso che è stato utilizzato un certificato errato nel X-Security-Token:
X-Security-Token decodificato:
FSE-JWT-Signature Token decodificato:
Authorization Bearer Token decodificato:
Inoltre, FSE-JWT-Signature Token e Authorization Bearer Token sono stati creati usando due certificati diversi. La invitiamo a riprovare utilizzando il certificato S1#111#PUNTOZEROXX al posto di A1#111#100XXXXXXXX. Rimaniamo a disposizione. Grazie.
Abbiamo aggiornato il certificato del X-Security-Token. Per quanto riguarda i token JWT otteniamo di nuovo un HTTP 403 in ambo i casi
{
"type": "https://govway.org/handling-errors/403/AuthorizationContentDeny.html",
"title": "AuthorizationContentDeny",
"status": 403,
"detail": "Unauthorized request content",
"govway_id": "1e438084-8241-11ef-a6bf-005056ae7395"
}
{
"type": "https://govway.org/handling-errors/403/AuthorizationContentDeny.html",
"title": "AuthorizationContentDeny",
"status": 403,
"detail": "Unauthorized request content",
"govway_id": "7bb77434-8241-11ef-a6bf-005056ae7395"
}
Analizzando i token, si nota che ha utilizzato due certificati diversi per generarli:
FSE-JWT-Signature Token decodificato:
Authorization Bearer Token decodificato:
Potrebbe gentilmente effettuare una prova usando lo stesso certificato S1#100#REGIONEUMBRIATEST per crearli in modo tale che l'iss coincida al netto dei prefissi integrity:/auth:? Grazie.
Se uso S1#100#REGIONEUMBRIATEST
la chiamata funziona dato che è quella che stiamo usando anche per il crash program.
Il problema, come ho scritto sopra, nasce quando i JWT vengono firmati dai produttori del documento e non dal middleware. I due punti che ho riportato nel commento precedente servono proprio a mostrare questo comportamento.
In sostanza la tabella seguente riassume i comportamenti ottenuti.
MTLS Cert | JWT Auth Cert | JWT Signature Cert | Esito | |
---|---|---|---|---|
1 | A1#100#REGIONEUMBRIATEST | S1#100#REGIONEUMBRIATEST | S1#100#REGIONEUMBRIATEST | 200 |
2 | A1#100#REGIONEUMBRIATEST | S1#100#REGIONEUMBRIATEST | S1#111#PUNTOZEROXX | 403 |
3 | A1#100#REGIONEUMBRIATEST | S1#111#PUNTOZEROXX | S1#111#PUNTOZEROXX | 403 |
Dove la riga
Quindi, come dobbiamo fare per poter usare i token del produttore senza doverli rifirmare?
Buongiorno, la avvisiamo che stiamo effettuando ulteriori verifiche sui controlli di coerenza di govway. Se prima della risoluzione della presente issue desidera fare dei test, può fornirci delle nuove CSR per creare dei certificati per il producer con "100" anziché "111". Grazie.
Salve, abbiamo bisogno di una precisazione riguardo l'utilizzo dei token JWT.
Regione Umbria è strutturata come middleware regionale, ricade quindi nella soluzione di tipo 1 indicata nelle specifiche Github dove il middleware si preoccupa di stabilire la connessione MTLS verso il GTW nazionale tramite apposito certificato, mentre la firma dei JWT è demandata al produttore.
A scopo di recap, i JWT in ogni richiesta sono 2
Da un precedente scambio di email ci avete indicato che nella configurazione di cui sopra, il token 1 ovvero il
JWT auth
deve essere firmato dal middleware mentre il 2 ovvero ilJWT signature
deve essere firmato dal produttore.Stiamo effettuando dei test di validazione di un documento solo per testare la connettività, ma otteniamo solo risposte HTTP 403.
Esempio di chiamata
CN certificato MTLS: A1#100#REGIONEUMBRIATEST issuer JWT Auth: auth:S1#100#REGIONEUMBRIATEST issuer JWT signature: integrity:S1#111#PUNTOZEROXX
Esempio di risposta
Stiamo sbagliando qualche cosa?