Errore InteroperabilityInvalidRequest su https://apigw-test.anticorruzione.it/modi/rest/CodeList/v2/

[petromanco]

Eseguendo la chiamata verso le api https://apigw-test.anticorruzione.it/modi/rest/CodeList/v2/ sia per gli 'status' che 'recupera-elenco-tipologiche' riceviamo il seguente errore:

{ "type": "https://govway.org/handling-errors/400/InteroperabilityInvalidRequest.html", "title": "InteroperabilityInvalidRequest", "status": 400, "detail": "Received request is not conform to the required interoperability profile", "govway_id": "2908ce62-2975-11ef-8dc0-0050568e08b3" }

Abbiamo Generato l'access_token seguendo questi passaggi:

1. Abbiamo Generato e firmato con la chiave privata relativa alla chiave pubblica usata per configurare il client il primo JWS, che chiameremo JWS_1, utilizzando il codice python fornito dalla piattaforma PDND, propriamente modificato, settando questi campi:

headers = { "kid": args.kid, "alg": "RS256", "typ": "JWT", }

payload = { "iss": args.issuer, "sub": args.subject, "aud": args.audience, "purposeId": args.purposeId, "jti": str(jti), // calcolato "iat": issued, // calcolato "exp": expire_in // calcolato }

Il valore dell'audience, per questo JSW, è stato settato a quello del servizio del fornitore: apigw-test.anticorruzione.it/modi/rest/CodeList/v2

2. Abbiamo generato il digest codificando il JWS del punto 1 utilizzando il seguente comando: echo -n [JWS] | openssl SHA256

3. Abbiamo Generato e firmato con la chiave privata relativa alla chiave pubblica usata per configurare il client il secondo JWS, che chiamermo JWS_2, utilizzando il codice python fornito dalla piattaforma PDND, propriamente modificato, agiungendo anche il valore digest del punto 2:

headers = { "kid": args.kid, "alg": "RS256", "typ": "JWT", "digest": { "algorithm": "SHA-256", "value": args.digest } }

payload = { "iss": args.issuer, "sub": args.subject, "aud": args.audience, "purposeId": args.purposeId, "jti": str(jti), // calcolato "iat": issued, // calcolato "exp": expire_in // calcolato }

Il valore dell'audience, per questo JWS, è stato settato a quello del servizio di autenticazione di interoperabilità: auth.uat.interop.pagopa.it/client-assertion

4. Abbiamo generato l'access_token inviando una richiesta POST all'endpoint: https://auth.uat.interop.pagopa.it/token.oauth2 settando i seguenti campi:

client_id: [CLIENT_ID] client_assertion: [JWS_2] client_assertion_type:urn:ietf:params:oauth:client-assertion-type:jwt-bearer grant_type:client_credentials

Questa richiesta ci ha generato l'access_token JWT da utilizzare come Bearer nelle richieste verso il fornitore

5. Effettuando una richiesta GET verso https://apigw-test.anticorruzione.it/modi/rest/CodeList/v2/status settando i seguenti headers:

Authorizazion: Bearer [JWT], Agid-JWT-TrackingEvidence: [JWS_1]

Riceviamo l'errore di cui sopra che riportiamo:

{ "type": "https://govway.org/handling-errors/400/InteroperabilityInvalidRequest.html", "title": "InteroperabilityInvalidRequest", "status": 400, "detail": "Received request is not conform to the required interoperability profile", "govway_id": "2908ce62-2975-11ef-8dc0-0050568e08b3" }

Dove stiamo sbagliando?

[obigno77]

Validazione security token ModI 'AUDIT' della richiesta fallita: [Header 'Agid-JWT-TrackingEvidence'] Signature verification failed: [COMPACT] Signature verification failure: Process 'kid' error: INVALID_KEY

[petromanco]

@obigno77 il kid viene modificato quando richiamiamo l'endpoint https://auth.uat.interop.pagopa.it/token.oauth2 per generare l'access_token.

Come possiamo risolvere?

[wevitt]

Seguo. Anche noi abbiamo lo stesso problema: Decodificando il primo ed il secondo JWS il Kid rimane invariato, ovvero quello dato in pasto alla funzione python. Generando l'access token e decodificandolo abbiamo notato che il valore del KID è diverso. Domanda: l'header Agid-JWT-TrackingEvidence deve essere valorizzato con il JWS con o senza digest?

[obigno77]

@petromanco nel vostro caso non stiamo proprio ricevendo il token jws @petromanco @wevitt vi invito a vedere la issue #352