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. 854 Profilo ModI della govwayMonitor
L’esecuzione dello scenario è del tutto analogo a quello descritto nello scenario Esecuzione con la sola eccezione del pattern di sicurezza aggiuntivo utilizzato in questo scenario: «INTEGRITY_REST_02».
Per eseguire e verificare lo scenario si può utilizzare il progetto Postman a corredo con la request «Profilo ModI REST - IntegrityRest02+PDND - IN App3» che è stata preconfigurata per il funzionamento con le caratteristiche descritte sopra.
Fig. 855 Pattern IntegrityRest02+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”.
Nota
Le informazioni ottenute tramite le API PDND (chiavi pubbliche JWK e informazioni sui client) vengono salvate su cache locali. Al fine di forzare nuove invocazioni verso la «PDND simulata» è necessario attendere un minuto rispetto a precedenti invocazioni ed effettuare il reset delle cache locali di GovWay accedendo alla sezione Runtime della console di gestione “govwayConsole” e cliccando sul link “Svuota tutte le Cache”.
Le evidenze del processo di validazione relative al token PDND sono le medesime descritte nella scenario Esecuzione.
Dal dettaglio della richiesta si può visualizzare il messaggio che è stato inviato dal fruitore, come in Fig. 816. Come si nota, al payload JSON è associato un insieme di header HTTP tra i quali «Authorization» e «Agid-Jwt-Signature» che contengono rispettivamente il token di sicurezza che il fruitore ha ottenuto dalla PDND e il token di integrità. È inoltre presente l’header http «Digest» che contiene il valore per la verifica dell’integrità del payload.
Grazie alle configurazioni presenti nell’erogazione, ed in particolare all’indicazione che il token ricevuto deve essere validato tramite Token Policy PDND, GovWay è in grado di validare i dati di sicurezza ricevuti (Fig. 856) e decodificare il token.
Fig. 856 Evidenza diagnostica della validazione del token
Vengono inoltre validati gli ulteriori header «Agid-Jwt-Signature» e «Digest» rispetto al pattern “INTEGRITY_REST_02” indicato nella configurazione dell’API (Fig. 857). La validazione del token di integrità viene effettuata scaricando la chiave pubblica, corrispondente al kid presente nel token, tramite le API PDND. Nello storico delle transazioni è possibile vedere come GovWay durante la gestione della richiesta di erogazione scaturisca un’ulteriore chiamata verso la PDND per ottenere la chiave pubblica (Fig. 858). La chiave pubblica una volta prelevata dalla PDND verrà aggiunta in una cache locale e le successive richieste non provocheranno ulteriori chiamate verso la PDND.
Fig. 857 Evidenza diagnostica della validazione del token di integrità
Fig. 858 Evidenza diagnostica della chiamata verso la PDND per ottenere la chiave pubblica
Analizzando il token di integrità «Agid-Jwt-Signature» ricevuto nella sezione header (Fig. 859) si può notare che non viene riportata l’identità del fruitore tramite certificato X.509 come avveniva per il pattern INTEGRITY_REST_01 descritto nella scenario Pattern “INTEGRITY_01” ma bensì tramite il claim “kid” che corrisponde all’identificativo della chiave pubblica registrata sulla PDND. L’identificativo “kid” verrà utilizzato da GovWay per richiedere la chiave pubblica tramite le API PDND (Fig. 860). Nella sezione payload (Fig. 861) sono invece presenti gli header http firmati (tra cui il valore dell’header “Digest”) che servono a garantire l’integrità della richiesta, insieme ai riferimenti temporali (iat, nbf, exp) e all’audience (aud).
Fig. 859 Sezione «Header» del Token “Agid-Jwt-Signature” con pattern “INTEGRITY_REST_02”
Fig. 860 Dettaglio della url di invocazione utilizzata da GovWay per prelevare la chiave pubblica dalla PDND
Fig. 861 Sezione «Payload» del Token “Agid-Jwt-Signature” con pattern “INTEGRITY_REST_02”
Vengono inoltre recuperate e associate alla traccia maggiori informazioni sull’organizzazione afferente al “client-id” presente nel token, sempre attraverso le API PDND (Fig. 862). Nello storico delle transazioni è possibile vedere come GovWay durante la gestione della richiesta di erogazione scaturisca due ulteriori chiamate verso la PDND per ottenere maggiori informazioni sul client e sull’organizzazione (Fig. 863). Le informazioni recuperate dalla PDND verranno aggiunte in una cache locale e le successive richieste non provocheranno ulteriori chiamate verso la PDND.
Fig. 862 Informazioni recuperate dalla PDND sull’organizzazione associata al “client-id”
Fig. 863 Evidenza diagnostica delle chiamate verso la PDND per ottenere maggiori informazioni sul “client-id”
Le evidenze del processo di validazione relativo al pattern «INTEGRITY_REST_02» sono visibili sulla govwayMonitor, andando a consultare la traccia del messaggio di richiesta (Fig. 864). Nella sezione «Sicurezza Messaggio» sono riportate le informazioni estratte dai token di sicurezza presenti, tra cui si può notare il digest e gli header http firmati.
Fig. 864 Traccia della richiesta elaborata dall’erogatore, con pattern “INTEGRITY_REST_02”
Conformità ai requisiti ModI
I requisiti iniziali, legati alla comunicazione basata su uno scenario ModI, sono verificati dalle seguenti evidenze:
la sicurezza messaggio applicata è quella dei pattern «ID_AUTH_REST_01 via PDND» + «INTEGRITY_REST_02» come ampiamente mostrato precedentemente dove sono stati mostrati i token validati e i criteri autorizzativi;
la validazione del token di integrità viene effettuata scaricando la chiave pubblica, corrispondente al kid presente nel token, tramite le API PDND;
l’identificazione del fruitore avviene rispetto al claim “client_id” presente all’interno del token e ulteriori informazioni sull’organizzazione afferente vengono ottenute invocando le API PDND.
