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. 709 Profilo ModI della govwayMonitor
L’esecuzione dello scenario si basa sui seguenti elementi:
una API SOAP di esempio (Temperature Conversion) definita con pattern di interazione Bloccante e pattern di sicurezza «ID_AUTH_CHANNEL_02» e «ID_AUTH_SOAP_01»»;
un’istanza Govway per la gestione del profilo ModI nel dominio dell’erogatore;
un client del dominio esterno che invoca l’azione di esempio «CelsiusToFahrenheit» dell’erogazione esposta da Govway;
il server “Temperature Conversion” di esempio che riceve le richieste inoltrate dal Govway e produce le relative risposte. Per questo scenario viene utilizzato il server disponibile on line all’indirizzo “https://www.w3schools.com/xml/tempconvert.asmx”.
Per eseguire e verificare lo scenario si può utilizzare il progetto Postman a corredo con la request «Profilo ModI SOAP - IDAuth - IN App1» che è stata preconfigurata per il funzionamento con le caratteristiche descritte sopra.
Fig. 710 Pattern IDAuth - Erogazione API SOAP, 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.
Per verificare l’utilizzo del canale SSL, in accordo al pattern «ID_AUTH_CHANNEL_02», si procede come già illustrato per Esecuzione
Dal dettaglio della richiesta si può visualizzare il messaggio che è stato inviato dal fruitore, come in Fig. 711. Come si nota, il messaggio SOAP contiene nell’header WS-Security sia il token di sicurezza (elemento «BinarySecurityToken») sia l’elemento «WSAddressing - To» prodotti dal fruitore con la relativa firma digitale (elemento «SignatureValue»).
Fig. 711 Messaggio inviato dal fruitore
3. Il messaggio ricevuto dal Govway viene quindi validato, sulla base dei pattern di sicurezza previsti nello scambio, verificando in questo caso l’identità del fruitore, la validità temporale, la corrispondenza dell’audience ricevuto con quello atteso. Solo in caso di superamento dell’intero processo di validazione, il messaggio viene inoltrato al servizio erogatore. Le evidenze del processo di validazione sono visibili sulla govwayMonitor, andando a consultare la traccia del messaggio di richiesta (Fig. 712). Nella sezione «Sicurezza Messaggio» sono riportate le informazioni estratte dal token di sicurezza presente nell’header soap.
Fig. 712 Traccia della richiesta elaborata dall’erogatore
Dopo l’inoltro al servizio erogatore, Govway riceve la risposta e la elabora producendo il relativo header ws-security da inserire nel messaggio di risposta. Sulla console govwayMonitor è possibile visualizzare il messaggio di risposta in uscita (analogamente a Fig. 711).
Lo scenario è preconfigurato per autorizzare puntualmente l’applicativo “App1-ModI” identificato grazie al certificato X.509 presente all’interno dell’header WSSecurity. È possibile utilizzare il progetto Postman a corredo con la request «Profilo ModI SOAP - IDAuth - IN App2 - Error» per verificare che una richiesta proveniente da un differente applicativo non viene autorizzata.
Fig. 713 Pattern IDAuth - Erogazione API SOAP - Autorizzazione negata, esecuzione da Postman
Conformità ai requisiti ModI
La verifica dei requisiti ModI per questo scenario non differisce da quanto già descritto in Esecuzione.
