problema verifica richiesta fruizione e-service da parte di erogatore

[sandrocianfarani]

Salve. Quello che non riusciamo a fare (noi sviluppiamo in php), è quanto descritto in questi step:

Sarebbe possibile avere un esempio esplicito di cosa fare? Magari se ci fosse uno script php di esempio sarebbe molto utile. Grazie

Il flusso in dettaglio

Il fruitore impacchetta le informazioni complementari Un JWS di esempio può avere header { "alg": "RS256", "kid": "ZmYxZGE2YjQtMzY2Yy00NWI5LThjNGItMDJmYmQyZGIyMmZh", "typ": "JWT" } Il payload sarà invece costituito dalle informazioni aggiuntive che il fruitore vuole trasmettere all'erogatore. Il fruitore firma quindi il JWS con una chiave privata. La chiave pubblica corrispondente deve essere depositata su PDND Interoperabilità e avere per kid quello inserito nell'header del JWS. NB: questa chiave e questo kid non devono necessariamente essere gli stessi con i quali si firma la client assertion al passaggio 3. Il fruitore calcola l'hash A partire dalla codifica del JWS (ossia il JWS codificato secondo l'algoritmo inserito nell'header, in genere inizia per ey) il fruitore applica l'algoritmo di hashing SHA256 al JWS, ottenendone un hash non reversibile a lunghezza fissa. A scopo esemplificativo, è possibile inserire in un terminale il seguente comando, previa installazione del pacchetto openssl echo -n {JWS} | openssl sha256 per ottenere l'hash del JWS. Ad esempio, a fronte del JWS esempio con codifica eyJhbGciOiJIUzI1NiIsImtpZCI6IlptWXhaR0UyWWpRdE16WTJZeTAwTldJNUxUaGpOR0l0TURKbVltUXlaR0l5TW1aaCIsInR5cCI6ImF0K2p3dCJ9.eyJqdGkiOiJkc2Zkc2Zkc2ZkcyIsImEiOiJiIn0.2QcY5UpoE2PgJhe1FKnHx-SZZq_NS6AKDTlfFdpVP9Q si ottiene l'hash a lunghezza fissa 5db26201b684761d2b970329ab8596773164ba1b43b1559980e20045941b8065 NB: la flag -n che viene passata nel primo comando indica che vengano rimosse eventuali "newline" non viste dall'operatore. Un'eventuale "newline" presente nel token fa cambiare il valore dell'hash che poi non corrisponderà all'atto della verifica dell'erogatore. Il fruitore costruisce la client assertion Il fruitore prende quindi l'hash appena ottenuto, e lo inserisce nel payload della client assertion nel campo digest.value. Il campo digest.alg per adesso accetta solamente il valore SHA256 (corrispondente all'algoritmo di hashing che è stato applicato al JWS). { ...[altri campi della client assertion da flusso standard], "digest": { "alg": "SHA256", "value": "5db26201b684761d2b970329ab8596773164ba1b43b1559980e20045941b8065" } } L'header della client assertion rimane invece invariato rispetto al flusso standard. La client assertion andrà firmata con la chiave privata corrispondente alla pubblica caricata su PDND Interoperabilità il quale kid è nell'header di questa asserzione. Il fruitore richiede un voucher a PDND Interoperabilità In questo passaggio non ci sono variazioni rispetto al flusso standard. Il fruitore fa una richiesta di voucher al server autorizzativo di PDND Interoperabilità inviando la client assertion. PDND Interoperabilità restituisce un voucher al fruitore Anche in questo passaggio non ci sono variazioni. Da notare che l'unica verifica che PDND Interoperabilità effettua sul campo digest è che rispetti la lunghezza della stringa prevista da SHA256 (64 caratteri). Il fruitore fa una richiesta di dati all'erogatore In questo passaggio, il fruitore costruisce una richiesta verso il servizio dell'erogatore secondo quanto descritto nel file di interfaccia e nella documentazione tecnica a corredo fornita dall'erogatore attraverso PDND Interoperabilità. Nella richiesta inserirà l'header standard Authorization che conterrà come Bearer token il voucher rilasciato da PDND Interoperabilità allo step precedente. Inoltre, il fruitore inserirà il JWS che contiene le informazioni complementari all'interno di un secondo header denominato Agid-JWT-TrackingEvidence. L'erogatore effettua le verifiche standard Per questo passaggio, si veda la sezione dedicata nel flusso standard. L'erogatore effettua le verifiche aggiuntive sul JWS Dopo aver completato le verifiche standard, l'erogatore può effettuare le verifiche aggiuntive necessarie a garantire l'attendibilità delle informazioni complementari inserite nel JWS aggiuntivo. Quindi verificherà l'autenticità e la validità della chiave privata con la quale è firmato il JWS. Per farlo: si autentica sulle API di Interoperabilità come descritto nel flusso dedicato; effettua una chiamata keys/{kid} dove kid è valorizzato con il kid inserito nell'header del JWS; ottiene da PDND Interoperabilità una chiave pubblica in risposta all'interno del campo n; verifica la firma del JWS, effettuata dal fruitore con la chiava privata, con la chiave pubblica appena ottenuta. Se l'erogatore ottiene un errore con status code 404 - Not found, significa che la chiave non è presente su PDND Interoperabilità e dunque la richiesta è da ritenersi inattendibile. L'erogatore calcola e confronta l'hash Se la chiave è presente e corrisponde, può procedere ad una seconda verifica, ossia quella notarile. In pratica, verifica che la traccia depositata su PDND Interoperabilità corrisponda a quella inserita all'interno del voucher rilasciato da PDND Interoperabilità. Se c'è corrispondenza, vuol dire che le informazioni complementari inserite all'interno del JWS sono effettivamente quelle che il fruitore ha dichiarato su PDND Interoperabilità di aver inserito. Per farlo, l'erogatore prende il JWS ed effettua la stessa operazione effettuata dal fruitore nel secondo passaggio. Ottiene quindi l'hash non reversibile del JWS. L'erogatore confronta quindi questo hash con quello presente all'interno del campo digest.value del voucher rilasciato da PDND Interoperabilità presente nell'header Authorization. Se i due hash sono uguali, il fruitore ha reso una dichiarazione che corrisponde ed è tracciata su PDND Interoperabilità.

[FedericaSicchiero]

Salve, in piattaforma è disponibile un esempio in python per la generazione di una client assertion. Rispetto a quello che avete chiesto nella issue è sufficiente inserire un claim digest costruito secondo le indicazione che avete riportato e che sono presenti in guida.

[sandrocianfarani]

Grazie per la risposta. La gestione della client assertion la effettuiamo già correttamente. Il problema è che non riusciamo a capire come verificare la richiesta del fruitore come da manuale:

Verifica sulla firma L'erogatore scarica la lista di chiavi in uso da un file esposto nella cartella .well-known di PDND Interoperabilità (l'URL corretta è disponibile sull'interfaccia nel back office all'interno della scheda di ogni singolo e-service e cambia in funzione dell'ambiente; a titolo esemplificativo, questa è quella di produzione).

Come vedete in questa immagin indicate che si debba raggiungere una url .well-known che non è presente sulla pagina PDND Interoperabilità. Come possiamo proseguire?

All'interno del file, l'erogatore cerca l'oggetto che ha lo stesso kid presente nell'header del voucher. In quello stesso oggetto troverà la chiave pubblica al parametro n. Effettuerà dunque una verifica della firma, che la chiave privata usata per firmare il voucher corrisponda a quella pubblica appena ottenuta.

Grazie

[FedericaSicchiero]

Buongiorno, grazie della segnalazione sulla documentazione che ora andiamo ad aggiornare perchè lo screen non è più al passo con le modifiche della UI. Ora - come da screen - il well-known si trova all'interno dell'e-service, dove dopo aver cliccato su "Vedi i dettagli tecnici dell'e-service" si apre la tendina con tutte le informazioni.

[nahid998]

Io se apro la tendina non sono presenti le opzioni in basso a destra, cosa potrebbe significare?

[FedericaSicchiero]

Per quale e-service e con quale ruolo state facendo le prove? Che potrebbe dipendere da vari fattori, anche solo se l'e-service non è in stato Attivo ma Sospeso

[nahid998]

per C020-servizioAccertamentoResidenza-approvazione_automatica, e scusa se chiedo ma cosa intendi come ruolo? Erogatore Fruitore o sviluppatore?

[FedericaSicchiero]

Come ruolo intendo se Amministratore, Operatore API o Operatore di sicurezza. Con quale ente poi state lavorando?

[nahid998]

Operatore di sicurezza, come puoi vedere dalle immagini, noi siamo su FRUIZIONE, ma il problema è che quando utilizziamo il voucher per mandare la richiesta su postmand all'audience ci esce un 404 - Not found

[FedericaSicchiero]

Avete provato ad usare il tool di debug del voucher e vedere cosa vi risponde come errore?

[nahid998]

non ci esce nessun errore nel tool di debug,

[nahid998]

il voucher funziona ma quando proviamo ad usarlo nel e-service (https://modipa-val.anpr.interno.it/govway/rest/in/MinInternoPortaANPR/C020-servizioAccertamentoResidenza/v1/) esce l'errore 404 - not found e non riusciamo a capire il perché

[sandrocianfarani]

Buongiorno, grazie della segnalazione sulla documentazione che ora andiamo ad aggiornare perchè lo screen non è più al passo con le modifiche della UI. Ora - come da screen - il well-known si trova all'interno dell'e-service, dove dopo aver cliccato su "Vedi i dettagli tecnici dell'e-service" si apre la tendina con tutte le informazioni.

Salve. Nel mio ambiente di Interoperabilità Collaudo, non trovo informazioni come da vostro commento.

Personalmente continuo ad avere difficoltà tra la documentazione fornita e gli sviluppi da fare.

[FedericaSicchiero]

@sandrocianfarani grazie della segnalazione, vuol dire che c'è un disallineamento tra i nostri ambienti che andremo a sistemare, tra oggi e domani rilasceremo i fix.

[FedericaSicchiero]

@sandrocianfarani abbiamo rilasciato ieri tutta una serie di fix tra cui dovrebbe essere presente anche quello della issue. Se gentilmente potete provare a vedere che lato vostro funzioni tutto, grazie