Esecuzione¶

Nota

Al fine di avere una consultazione immediata delle informazioni di interesse per lo scenario si consiglia di impostare, nella console “govwayMonitor”, nel menù in alto a destra il Profilo di Interoperabilità “ModI”. Si suggerisce inoltre di selezionare il soggetto “Ente” per visualizzare solamente le transazioni di interesse allo scenario e ignorare le transazioni «di servizio» necessarie ad implementare la controparte.

Fig. 856 Profilo ModI della govwayMonitor¶

L’esecuzione dello scenario è del tutto analogo a quello descritto nello scenario Esecuzione. Di seguito verranno evidenziate solamente le differenze che comporta l’utilizzo del pattern «AUDIT_REST_02» al posto di «AUDIT_REST_01».

Per eseguire e verificare lo scenario si può utilizzare il progetto Postman a corredo con la request «Profilo ModI REST - Audit02+PDND - IN App4» che è stata preconfigurata per il funzionamento con le caratteristiche descritte sopra.

Fig. 857 Pattern Audit02+PDND - Erogazione API REST, esecuzione da Postman¶

Dopo aver eseguito la «Send» e verificato il corretto esito dell’operazione è possibile andare a verificare cosa è accaduto, nel corso dell’elaborazione della richiesta, andando a consultare la console “govwayMonitor”.

Le evidenze del processo di validazione relative al token PDND sono le medesime descritte nella scenario Esecuzione.

Le evindenze del processo di validazione del token di audit «Agid-Jwt-TrackingEvidence» sono le stesse descritte nello scenario Esecuzione. Di seguito viene riportato solamente un dettaglio differente presente all’interno del token «Authorization» e richiesto dal pattern «AUDIT_REST_02» per implementare la correlazione tra il token di autenticazione e il token di audit.

Analizzando il token di auth «Authorization» ricevuto nella sezione payload (Fig. 858) oltre alle consuete informazioni sull’identità del fruitore (client_id), i riferimenti temporali (iat, nbf, exp), l’audience (aud) e il “purposeId” utilizzato dal fruitore per richiedere il token di autorizzazione alla PDND, è presente anche il claim “digest” utilizzato dall’erogatore per verificare la corrispondenza rispetto al digest calcolato sul token di audit «Agid-Jwt-TrackingEvidence» ricevuto.

Fig. 858 Sezione «Payload» del Token “Authorization” con pattern “AUDIT_REST_02”¶

Conformità ai requisiti ModI

La verifica dei requisiti ModI per questo scenario non differisce da quanto già descritto in Esecuzione.