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. 718 Profilo ModI della govwayMonitor¶

L’esecuzione dello scenario si basa sui seguenti elementi:

• una API REST di esempio (PetStore) definita con pattern di interazione “CRUD” e pattern di sicurezza «ID_AUTH_CHANNEL_01» e «ID_AUTH_REST_01 via PDND»;

• un’istanza Govway per la gestione del profilo ModI nel dominio del fruitore;

• un’authorization server che simula la PDND;

• un client che invoca la risorsa «POST /pet» con un messaggio di esempio diretto alla fruzione configurata su Govway.

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

Fig. 719 Pattern IDAuth+PDND - Fruizione API REST, esecuzione da Postman¶

Dopo aver eseguito la «Send» e verificato il corretto esito dell’operazione è possibile andare a verificare cosa è accaduto nelle diverse fasi dell’esecuzione andando a consultare la console “govwayMonitor”.

1. Il messaggio di richiesta inviato dal fruitore viene elaborato da Govway che, tramite la configurazione della firma digitale associata all’applicativo mittente, è in grado di produrre un token di sicurezza da inviare alla PDND con il quale ottenere indietro un voucher spendibile per il servizio desiderato. Tramite la console è possibile esaminare sia l’asserzione JWT inviata alla PDND (Fig. 720) che l’access token ottenuto dalla PDND (Fig. 721).

Fig. 720 Evidenza dell’asserzione JWT inviata alla PDND¶

Fig. 721 Evidenza dell’access token ottenuto dalla PDND¶

2. Esaminando l’header e il payload dell’asserzione JWT inviata alla PDND (Fig. 722) si può notare:

• Valore del claim “kid” associato all’applicativo mittente in configurazione

• Valore del claim “client_id” (uguale per i claim “sub” e “iss”) associato all’applicativo mittente in configurazione

• Valore del claim “purposeId” indicato dal client (nell’esempio Postman) tramite un header http “X-Purpose-Id”

Fig. 722 Header e Payload dell’asserzione JWT inviata alla PDND¶

3. Analizzando l’access token ricevuto dalla PDND, nella sezione header (Fig. 723) si può notare che non viene riportata l’identità del fruitore tramite certificato X.509 come avveniva per il pattern ID_AUTH_REST_01 descritto nella scenario Esecuzione. L’identità del fruitore è presente nella sezione payload (Fig. 724) all’interno del claim client_id, insieme ai riferimenti temporali (iat, nbf, exp) e all’audience (aud) del servizio per cui si è richiesto il voucher. Da notare inoltre la presenza del claim “purposeId” che servirà ad indicare la finalità per cui il fruitore sta fruendo del servizio all’erogatore.

Fig. 723 Sezione «Header» del Token PDND¶

Fig. 724 Sezione «Payload» del Token PDND¶

4. Tramite la console govwayMonitor si può visualizzare il messaggio di richiesta in uscita che è il medesimo di quello in entrata con la differenza che è stato aggiunto l’access token ottenuto dalla PDND tra gli header HTTP all’interno dell’header «Authorization» (Fig. 725).

Fig. 725 Messaggio di richiesta in uscita (con voucher PDND inserito nell’header HTTP)¶

5. Govway riceve la risposta dell’erogatore grazie al fatto che ha inviato un voucher PDND correttamente validato dall’erogatore.

Conformità ai requisiti ModI

I requisiti iniziali, legati alla comunicazione basata su uno scenario ModI, sono verificati dalle seguenti evidenze:

1. viene effettuata una negoziazione del voucher PDND come mostrato nelle tracce relative ai token scambiati con la PDND;

2. l’invocazione del servizio avviene fornendo il voucher della PDND precedentemente negoziato.