GovWay v3.3.5

Miglioramenti al Profilo di Interoperabilità 'ModI'

Sono stati apportati i seguenti miglioramenti:

• Contemporaneità degli Header 'Authorization' e 'Agid-JWT-Signature': su API REST, per quanto concerne la sicurezza messaggio, è stata aggiunta la possibilità di generare contemporaneamente gli header 'Authorization' e 'Agid-JWT-Signature' consentendo di agire sulle seguenti configurazioni:

  • è possibile indicare se la contemporaneità vale solo per la richiesta o in entrambi i flussi;

  • aspetti configurabili in fase di produzione del token:

    • generazione dei claim 'jti' e 'aud' identici o differenti nei 2 token;

    • possibilità di personalizzare ulteriori claim (compresi 'sub' e 'iss' e 'client_id') anche solo in uno dei due header;

  • aspetti configurabili in fase di validazione del token:

    • selezione dell'header da cui estrarre l'identificativo 'jti' utilizzato per filtrare le richieste duplicate;

    • indicare un audience atteso differente tra i due token.

  La generazione contemporanea dei 2 header nella richiesta e del solo header 'Agid-JWT-Signature' nella risposta diventa il default proposto con un pattern di sicurezza 'Integrity'.

• Custom Claims: è adesso possibile aggiungere nel payload del token JWT, su API REST, ulteriori claims oltre a quelli standard generati da GovWay oltre a poter sovrascrivere i valori di default assegnati ai claims standard (es. 'iss', 'sub', 'client_id') o disabilitarne la generazione;

• PKCS11: è stata aggiunta la possibilità di configurare un keystore HSM via 'PKCS11' per accedere alla chiave privata da utilizzare per la firma del token di sicurezza; il keystore è associabile all'applicativo che deve firmare il token di richiesta e all'erogazione che deve firmare il token di risposta;

• Validazione Audience Risposta: come audience atteso per un token della risposta è adesso possibile configurare un valore statico sulla fruizione, invece di usare il valore associato ad ogni applicativo fruitore;

• TTL in Validazione: sulla singola erogazione (configurazione 'ModI' della richiesta) o sulla fruizione (configurazione 'Modi' della risposta) è adesso possibile configurare un intervallo temporale (in secondi) per cui i token creati precedentemente all'intervallo indicato verranno rifiutati; la nuova opzione consente di sovrascrivere la configurazione di default in cui i token vengono rifiutati se sono stati creati da più di 5 minuti;

• Token Sicurezza nelle Tracce: in accordo a quanto richiesto dalle linee guida ModI, è stato modificato il comportamento di default di GovWay il quale non salva più i token di sicurezza scambiati;

• Multi-Tenant Intra-Dominio con modalità 'FileSystem': nella registrazione degli applicativi client sul profilo ModI, nella sezione relativa alla sicurezza messaggio, è adesso possibile caricare il certificato anche con la modalità 'filesystem' e 'hsm'. Il caricamento del certificato consente la corretta identificazione dell'applicativo su un altro dominio gestito sempre nella stessa installazione govway.

Sono inoltre stati risolti i seguenti problemi:

• la configurazione delle proprietà 'org.openspcoop2.protocol.modipa.rest.securityToken.claims.iat.minutes' e 'org.openspcoop2.protocol.modipa.soap.securityToken.timestamp.created.minutes' con valori superiori alle 3 settimane venivano ignorati.

Sono stati infine apportati i seguenti miglioramenti alla console di gestione:

• nei criteri di ricerca delle API, delle Erogazioni e delle Fruizioni è stata aggiunta una sezione dedicata al profilo 'ModI' che consente di filtrare per pattern di sicurezza canale, sicurezza messaggio, digest della richiesta e informazioni utente. Inoltre nelle Erogazioni/Fruizioni è consentito filtrare per keystore e audience;

• nei criteri di ricerca degli Applicativi è stata aggiunta una sezione dedicata al profilo 'ModI' che consente di individuare gli applicativi per i quali è stata abilitata la sicurezza messaggio. La sezione consente anche di filtrare per keystore e identificativo client inserito nel token di sicurezza ModI;

• è stato aggiunta la possibilità di espandere o richiudere le sezioni 'Informazioni Utente' e 'Contemporaneità Token Authorization e Agid-JWT-Signature' presenti nella configurazione ModI delle Erogazioni o delle Fruizioni.

Miglioramenti alla Console di Gestione

Sono stati apportati i seguenti miglioramenti alla console di gestione:

• nei filtri di ricerca delle Erogazioni, Fruizioni e Applicativi è stata aggiunta una sezione dedicata ai dati sui connettori tramite la quale è possibile filtrare per tipo di connettore, endpoint, token policy e keystore (solo in https);

• nei filtri di ricerca delle Erogazioni, Fruizioni, Applicativi e Soggetti è stata aggiunta una sezione dedicata alle proprietà che consente di filtrare selezionando una proprietà tra quelle configurate e/o indicandone un valore;

• il criterio di ricerca, nelle Erogazioni e Fruizioni, che consente di filtrare per nome API e soggetto erogatore è stato disaccoppiato in modo da poter effettuare una ricerca composta su entrambi i criteri;

• nei connettori multipli di una erogazione è adesso possibile effettuare ricerche usando come criterio il nome, un filtro e i dati del connettore;

• tra i criteri di ricerca, negli Applicativi e nei Soggetti, è adesso possibile indicare oltre al tipo di credenziale (https/http-basic/principal) anche il valore stesso della credenziale (es. CN del certificato X.509);

• la maschera di gestione del controllo degli accessi di una Erogazione o Fruizione è stata ottimizzata in modo da espandere solamente le sezioni per cui è stata abilitata una funzionalità;

• aggiunto al widget che consente di caricare un file sulla console la possibilità di rimuovere tale scelta;

• tra le informazioni visualizzate per il certificato associato ad un soggetto o ad un applicativo è adesso presente anche il serial number in formato Hex;

• nella maschera di dettaglio di una erogazione o fruizione, in presenza di un connettore di lunghezza superiore ai 150 caratteri viene visualizzata una informazione troncata contenente il suffisso ' ...'; lo stesso accorgimento è stato adottato nelle liste degli header HTTP e dei parametri della URL configurabili nelle trasformazioni.

Miglioramenti alla Console di Monitoraggio

Sono stati apportati i seguenti miglioramenti alla console di monitoraggio:

• nelle ricerche che prevedono un intervallo temporale, è stata aggiunta la gestione del timeout, in modo da segnalare all'utente di restringere l'intervallo di ricerca quando i parametri indicati richiedono un tempo eccessivo di elaborazione;

• lo storico delle transazioni, dopo aver presentato i risultati della ricerca, fornisce adesso la possibilità di effettuare una nuova ricerca, con i medesimi criteri, senza dover riaprire il filtro. La nuova ricerca è attivabile attraverso un pulsante di refresh posto accanto alla lente che consente la riapertura del filtro;

• nelle ricerche puntuali per identificativo, un utente amministratore o un utente a cui sono stati associati più profili e/o soggetti può individuare una transazione appartenente ad un profilo o soggetto differente da quello selezionato in alto a destra nella console. L'anomalia viene segnalata all'utente tramite una finestra informativa visualizzata prima di poter accedere ai dettagli della transazione;

• la generazione dei report statistici è stata ottimizzata al fine di ridurre il numero di query effettuate sulla base dati statistica;

• migliorata funzionalità di export CSV tramite la console e l'API di monitoraggio dove sono state aggiunte le informazioni riguardanti: tipo API (rest/soap), gruppo, configurazione CORS, proprietà dell'autenticazione e dell'autorizzazione, attribute authority (attributi), configurazione dell'autorizzazione per contenuti, rate limiting, caching della risposta, trasformazioni, registrazione dei messaggi, metadati e handlers, configurazioni del profilo di interoperabilità ModI e Applicativo Server.

Nuova funzionalità per il supporto dei device pkcs11

È stata introdotta la possibilità d'uso di Keystore HSM via 'PKCS11' per tutte le funzionalità gestite da GovWay: nella configurazione dei connettore 'https', nelle funzionalità di sicurezza dei messaggi (WSSecurity, XMLSecurity e JOSE), nelle Token Policy di validazione e negoziazione, nelle Attribute Authority e nella gestione dei token di sicurezza previsti nel Profilo 'ModI'.

Nuova funzionalità di registrazione delle Attribute Authority

È adesso possibile censire Attribute Authority che consentono di definire politiche di controllo degli accessi basate sugli attributi.

Miglioramenti alle funzionalità base dell'API Gateway

• aggiunti i contesti 'api-soap', limitata alla gestione di API SOAP e 'api-rest' limitata alla gestione di API REST;

• i criteri dinamici, utilizzabili nelle trasformazioni, nei criteri di autorizzazione, nella definizione di endpoint dinamici dei connettori etc, consentono adesso di:

  • accedere alle proprietà definite negli applicativi e nei soggetti;

  • accedere alle proprietà indicate nella configurazione generale di GovWay;

  • leggere variabili di sistema e proprietà della jvm;

• la presenza dei file di configurazione esterna generati dall'installer, non è più necessaria per il corretto avvio di GovWay e possono essere quindi presenti solo nel caso di effettiva necessità di personalizzazione dei valori di default;

• in una installazione di tipo cluster dinamico, viene adesso utilizzato come id del nodo l'identificativo del gruppo;

• aggiunto il tipo di errore 'ConnectorNotFound' utilizzato per identificare la casistica in cui non sia stato possibile individuare il connettore che implementa l'API, in configurazioni con connettori multipli (es. con consegna condizionale);

• miglioramenti prestazionali introdotti utilizzando il semaforo ...

GovWay v3.3.4.p2

Miglioramenti alla funzionalità di Negoziazione Token

Aggiunto il supporto per la negoziazione di token tramite la modalità di autenticazione descritta nella sezione 2.2 del RFC 7523 (https://datatracker.ietf.org/doc/html/rfc7523#section-2.2). È possibile configurare la policy per firmare l'asserzione JWT di autenticazione tramite un certificato X.509 o tramite un client secret.

È adesso possibile configurare l'autenticazione server di una token policy per accettare qualsiasi certificato.

Bug Fix

Patch version che risolve bug importanti indicati di seguito. La lista completa dei bug risolti è disponibile in https://govway.readthedocs.io/it/latest/releaseNotes/3.3.4/bug_p2.html

• gli scope presenti in un access token con formato JWT non venivano identificati se la Token Policy associata per la validazione utilizzata il parser 'OpenID Connect - ID Token' comportando un errore di autorizzazione 'AuthorizationMissingScope';

• in caso di installazione Multi-Tenant, gli applicativi interni 'ModI' di un Tenant non venivano identificati sull'erogazione di un altro Tenant, facendo fallire eventuali autorizzazioni puntuali configurate nel controllo degli accessi;

• corretta un'anomalia presente nel connettore https, dove se veniva impostata una configurazione errata (es. path di un keystore inesistente), veniva segnalato un errore generico 'no SSLSocketFactory specified' invece della motivazione puntuale;

Per la console di gestione sono stati risolti i seguenti bug:

• la console non consentiva l'aggiornamento delle chiavi private registrate in modalità 'Archivio' (caricate su database), relativamente alla sezione 'sicurezza messaggio' degli applicativi e delle erogazioni nel profilo ModI;

• risolta anomalia presente nella gestione degli allegati delle API e delle Erogazioni e Fruizioni:

  • il caricamento di allegati xml e xsd falliva segnalando erroneamente un contenuto scorretto;

  • il caricamento di allegati di altro tipo veniva completato con successo sulla console anche se poi i dati salvati risultavano corrotti;

• nella scheda di dettaglio di una erogaziono o fruizione, sull'informazione riportata per il connettore è stata aggiunta l'indicazione sull'eventuale policy di negoziazione token configurata;

• i connettori multipli, definiti su di un'erogazione, non venivano cancellati dalla base dati in seguito all'eliminazione dell'erogazione causando il fallimento di una eventuale nuova creazione della medesima erogazione appena eliminata.

GovWay v3.3.4.p1

Bug Fix

Patch version che risolve bug importanti indicati di seguito. La lista completa dei bug risolti è disponibile in https://govway.readthedocs.io/it/latest/releaseNotes/3.3.4/bug_p1.html

• corretto problema introdotto nella versione 3.3.4 con l'ottimizzazione dei messaggi soap: le richieste che presentavano un carattere '\n', '\r' o '\t' nel root-element causavano un fallimento del parser il quale riportava erroneamente un errore simile al seguente:

  Caused by: org.xml.sax.SAXParseException: The end-tag for element type "rootElementName" must end with a '>' delimiter

• nei casi suddetti, in cui il parser andava in errore, la funzionalità di registrazione dei messaggi salvava un contenuto incompleto;

• l'header HTTP SOAPAction non risultava modificabile tramite una trasformazione;

Per la console di gestione sono stati risolti i seguenti bug:

• il bottone 'i' di informazione presente negli elementi 'checkbox' veniva erroneamente visualizzato spostato sulla destra;

• su un'installazione Tomcat, la sezione 'Runtime' non visualizzava correttamente le informazioni relative alle connessioni attive del database di configurazione;

• se nel controllo degli accessi veniva configurata un'autenticazione 'plugin', non venivano visualizzati i link necessari a registrare puntualmente gli applicativi e i soggetti.

Per la console di monitoraggio sono stati risolti i seguenti bug:

• risolta problematica che si presentava saltuariamente sul server.log dell'application server, riportando un errore simile al seguente:

  SEVERE [facelets.viewhandler] (default task-5) Error Rendering View[/transazioni/pages/form/dettagliMessaggioTab.xhtml]: java.lang.IllegalArgumentException: could not find dataTable with id 'diagnosticiTable_tbl'

GovWay v3.3.4

Miglioramenti alle funzionalità base dell'API Gateway

Sono stati introdotti significativi miglioramenti prestazionali:

• la gestione dei messaggi di API SOAP è adesso equivalente a quella delle API REST: se non sono attive funzionalità che richiedono l'accesso al contenuto del messaggio, la gestione avviene in 'Passthrough', senza introdurre nessun overhead nella trasmissione;

• per API SOAP, anche se viene richiesta la costruzione in memoria dell'oggetto DOM che rappresenta il messaggio, al backend verrà inoltrata esattamente la richiesta originale ricevuta dal client, preventivamente bufferizzata, se le funzionalità che hanno avuto bisogno di accedere all'oggetto DOM non lo hanno modificato;

• la connessione verso il database 'runtime' viene adesso negoziata solamente se richiesta da funzionalità che ne necessitano;

• i connettori http preservano il 'keep-alive';

• la SSLSocketFactory istanziata per i connettori https viene mantenuta in una apposita cache;

• le chiavi private accedute per funzionalità di firma e decrifratura vengono salvate in cache assieme ai keystore;

• sono adesso gestiti i seguenti generatori di UUID:

  • generatore uuid v4 che utilizza SecureRandom;

  • generatore uuid v1 con mac address configurabile (se non fornito viene utilizzato uno tra quelli appartenenti alle schede di rete disponibili sulla macchina);

  • per tutti i generatori è adesso possibile attivarne una versione 'ThreadLocal';

  • il default del prodotto è stato modificato da UUIDv4 (java.util.UUID senza ThreadLocal) a UUIDv1 (com.fasterxml.uuid.impl.TimeBasedGenerator con ThreadLocal).

È stata migliorata la generazione delle informazioni statistiche:

• i criteri di generazione dei report statistici utilizzano adesso un'identificazione dell'intervallo temporale inclusivo del giorno di interesse del report (es. >=2021-02-10 00:00:00.000), soluzione che risulta maggiormente efficente in presenza di partizionamento giornaliero delle transazioni;

• l'algoritmo di generazione delle statistiche è stato completamente rivisto:

  • le informazioni statistiche, comprensive di latenze, vengono adesso calcolate tramite un'unica query SQL in modo da essere maggiormente efficente in presenza di grande mole di dati;

  • l'aggiornamento dell'intervallo corrente è adesso transazionale;

  • aggiunto refresh della connessione ogni 300 secondi.

Infine sono stati apportati i seguenti ulteriori miglioramenti:

• per API di tipo REST è stato arricchito il diagnostico di consegna, in presenza di codice di risposta http 3xx, per registrare anche il valore dell'header http 'Location';

• la funzionalità 'ID Collaborazione' è stata ridenominata in 'ID Conversazione' e, se abilitata, l'header HTTP GovWay-Conversion-ID viene adesso sempre generato, anche nella richiesta capostipite della conversazione dove viene valorizzato con l'id di transazione della prima richiesta;

• aggiunti timeout per la lettura dello stream di dati relativo alla richiesta e alla risposta;

• aggiunta la possibilità di configurare ulteriori Content-Type associabili a richieste SOAP 1.2 (per default viene accettato solo 'application/soap+xml');

• l'autenticazione 'https', attivabile nel controllo degli accessi delle erogazioni e fruizioni, effettua adesso anche la verifica della validità temporale del certificato ricevuto;

• la lettura delle proprietà di configurazione dai file locali (es. govway_local.properties) è stata rivista per risolvere le variabili indicate nei file anche come variabile di sistema oltre che come variabili java;

• è stato rivisto il diagnostico relativo ad una richiesta duplicata al fine di fornire un messaggio più generico rispetto a quello precedente specifico per il profilo SPCoop;

• è stato modificata la configurazione di default del CORS per generare un header 'Access-Control-Max-Age' valorizzato con '28800' (8 ore).

Miglioramenti al Profilo di Interoperabilità 'ModI'

Sono stati apportati i seguenti miglioramenti:

• adeguamenti alla terminologia utilizzata dalla specifica finale del Modello di Interoperabilità:

  • ridenominato profilo 'ModI PA' in 'ModI';
  • adeguata terminologia da 'profilo' a 'pattern' per i pattern di Interazione, di Sicurezza Canale e di Sicurezza Messaggio;

• per API di tipo SOAP è adesso possibile attivare anche la firma degli allegati utilizzando il pattern di sicurezza 'INTEGRITY_SOAP_01';

• è stato abilitato per default il controllo che rifiuta token scaduti (default 5 minuti): la verifica viene effettuata verificando la data presente nel claim 'iat' del JWT per API REST o nell'elemento 'Create' del WSSecurity Timestamp per API SOAP;

• nella configurazione relativa alla sicurezza messaggio ModI di un applicativo di dominio interno è adesso possibile configurare il keystore per la firma indicandolo anche tramite un path su filesystem;

• aggiunta la possibilità, su API SOAP, di configurare ulteriori header soap da aggiungere agli elementi inclusi nella firma (la configurazione è disponibile utilizzando la console in modalità avanzata);

• tra le informazioni ModI presenti nella traccia vengono adesso riportati anche gli header soap firmati.

Sono inoltre stati risolti i seguenti problemi:

• nei Pattern di Interazione la validazione dei codici http su API REST bloccanti e non bloccanti viene adesso effettuata esclusivamente su codici di risposta che rientrano nelle casistiche 2xx o 3xx;

• nella validazione di un token JWT Modi per API REST con pattern INTEGRITY_REST_01 non veniva verificato che tra gli header firmati vi fosse obbligatoriamente l'header HTTP 'Digest' se la richiesta presentava un payload;

• la funzionalità 'Verifica Audience', della sezione Sicurezza Messaggio Risposta di una fruizione, veniva ignorata e la validazione effettuata anche se l'opzione era disabilitata.

Miglioramenti alla Console di Gestione

Sono stati apportati i seguenti miglioramenti alla console di gestione:

• aggiunta la possibilità di modificare il soggetto erogatore nelle fruizioni e nelle erogazioni (#63 e #64);

• aggiunto supporto per il caricamento di file multipli nelle schermate di aggiunta degli allegati nelle API e nelle Erogazioni e Fruizioni;

• aggiunta la possibilità di filtrare per API sulle erogazioni e fruizioni;

• nellla sezione 'Controllo degli Accessi':

  • l'autenticazione è adesso modificabile solamente se non sono stati indicati puntualmente degli applicativi o dei soggetti nel criterio di autorizzazione "per richiedente";

  • se viene selezionata una autenticazione differente da quella precedentemente impostata, gli eventuali link 'Applicativi' e 'Soggetti' presenti nella sezione "autorizzazione per richiedente" non vengono più visualizzati fino a che non viene effettuato il salvataggio del nuovo tipo di autenticazione

• nella configurazione dei gruppi di risorse di una erogazione o fruizione è adesso possibile filtrare per metodo http e path;

• aggiunta la possibilità di registrare proprietà generiche sui soggetti e sugli applicativi;

• la funzionalità 'In uso' per gli applicativi e per i soggetti mostra adesso anche per quali erogazioni e fruizioni sono compatibili rispetto al criterio di autorizzazione per ruoli impostato nel controllo degli accessi;

• durante la creazione di una erogazione o fruizione fino a che non viene selezionata una API non sono visualizzate le sezioni 'Controllo Accessi', 'Connettore' e 'ModI';

• il parametro 'Access-Control-Max-Age', per le richieste Preflight CORS, è adesso configurabile dalla console senza dover accedere alla modalità avanzata;

• aggiunta funzionalità di filtro per Tag nelle policy di Rate Limiting a livello di configurazione globale;

• nella configurazione del tracciamento, dove è possibile indicare gli esiti delle transazioni da registrare, viene adesso gestita tramite una voce dedicata l'esito relativo alla violazione di una policy di RateLimiting;

• nelle maschere di configurazione dei connettori:

  • è stata aggiunta la nota "Indicazione in millisecondi (ms)" nei campo relativi alla sezione "ridefinisci tempi di risposta";

  • nella maschera di configurazione di un connettore multiplo vengono adesso proposti i valori di default nella sezione "ridefinisci tempi di risposta", se abilitata

• aggiunta funzionalità di export/import per:

  • Token Policy

  • Policy di Rate Limiting del Controllo del Traffico

  • Regole di Proxy Pass

• è adesso possibile attivare una scadenza temporale alle password associate alle utenze delle console.

Miglioramenti alla Console di Monitoraggio

Sono stati apportati i seguenti miglioramenti alla console di monitoraggio:

• nella ricerca avanzata dello storico delle transazioni, se viene effettuata una ricerca che comprende qualsiasi profilo, le transazioni riportate nell'elenco visualizzano adesso anche il profilo di appartenenza;

• tra i criteri di generazione delle statistiche è adesso possibile filtrare per identificativo del cluster e del canale;

• corretto formato delle label dell'asse Y dei grafici: aggiunto separatore delle migliaia per una migliore visualizzazione delle label.

Miglioramenti alla funzionalità di Registrazione dei Messaggi

È stata rivista la registrazione dei messaggi in ingresso e in uscita per salvare direttamente lo stream dei dati.

L'analisi di eventuali strutture multipart viene demandata alla console di monitoraggio.

Miglioramenti alla funzionalità di Autenticazione degli Applicativi e dei Soggetti

È adesso possibile associare più di un certificato X.509 agli applicativi e ai soggetti in modo da poter gestire i periodi di transizione relativi all'aggiornamento di un certificato.

Modificata la configurazione di default, proposta durante la registrazione di un nuovo applicativo o soggetto, in modo da prevedere l'id...

GovWay v3.3.3

Miglioramenti al Profilo di Interoperabilità 'ModI PA'

Adeguato il profilo 'ModI PA' alla versione finale delle Linee Guida di Interoperabilità rilasciate in data 15/09/2020: https://trasparenza.agid.gov.it/archivio19_regolamenti_0_5386.html

• Nomenclatura: le maschere di configurazione sono state allineate alla nuova terminologia riguardante i pattern di interazione e sicurezza.

• Interazione CRUD: alle risorse di una API REST viene adesso per default assegnato il pattern di interazione 'CRUD_REST'.

• Interazione Bloccante e Non Bloccante su API REST: i profili bloccanti e non bloccanti sono adesso assegnabili alle risorse solamente se compatibili con i metodi HTTP e i codici di risposta richiesti dalla specifica.

• Firma del payload su API REST: sostituito l'header 'Authorization' con il nuovo header 'Agid-JWT-Signature' per il pattern di sicurezza 'INTEGRITY_REST_01'.

• Rate Limiting: aggiunta gestione 'window' come descritto in 'https://datatracker.ietf.org/doc/draft-polli-ratelimit-headers/'. La funzionalità è attivabile tramite la proprietà 'org.openspcoop2.pdd.controlloTraffico.numeroRichieste.header.limit.windows=true' da registrare nel file govway_local.properties

• X5U per Applicativo: la url indicata nel claim 'x5u' di un token di sicurezza per API REST deve adesso essere registrata sull'applicativo e non più sulla fruizione in modo da consentire url differenti per applicativi differenti.

• Certificate Chain per API REST: aggiunta la possibilità di inviare l'intera catena dei certificati anche per API REST all'interno del claim 'x5c'.

• Sicurezza Messaggio su Richiesta/Risposta: è adesso possibile attivare la sicurezza messaggio puntualmente solamente sulla richiesta o sulla risposta di una operazione. Per API REST è possibile anche definire dei criteri di applicabilità della sicurezza messaggio in base a Content-Type o codici di risposta HTTP.

Miglioramenti alle Console di Gestione

Sono stati apportati i seguenti miglioramenti alle funzionalità di ricerca della console di gestione:

• Restyling grafico delle liste accessibili dal menù principale relativamente per i Soggetti, gli Applicativi, i Ruoli e gli Scope.

• Introdotti nuovi criteri di filtro per la ricerca degli applicativi e dei soggetti. È adesso possibile ricercarli per il loro utilizzo in erogazioni o fruizioni, anche specializzando la ricerca per tag o singola implementazione di API.

• Per tutti i principali oggetti presenti nel Registro (api, applicativi, soggetti, ruoli, scope ...) è adesso possibile conoscere in dettaglio dove sono utilizzati nelle configurazioni delle erogazioni e fruizioni.

• Il filtro di ricerca 'API / Soggetto Erogatore', presente tra i criteri di ricerca nella lista delle erogazioni o fruizioni, permetteva di individuare tutte le entità che contengono il parametro di ricerca indicato nel nome del soggetto erogatore o nel nome stesso associato alla erogazione o fruizione. Il parametro viene adesso utilizzato anche per verificare una corrispondenza sul nome dell'API implementata che, soprattutto in API di tipo SOAP dove viene utilizzato il nome del port-type, può differire dal nome dell'erogazione o fruizione.

• Dopo aver creato un oggetto sul registro, il filtro di ricerca viene impostato automaticamente con il nome di tale oggetto al fine di poterlo visualizzare immediatamente nella lista.

• Il filtro per Tag presente nei criteri di ricerca presenta adesso solamente i tag assegnati alle API relative al Profilo di Interoperabilità selezionato.

• Durante l'aggiornamento dell'interfaccia di un API è adesso possibile:

  • indicare se aggiornare o meno le risorse/azioni esistenti;
  • indicare se eliminare le risorse non più esistenti nella nuova interfaccia.

Miglioramenti alla Console di Monitoraggio

Sono stati apportati i seguenti miglioramenti alle funzionalità di ricerca della console di monitoraggio:

• È adesso possibile ricercare transazioni o ottenere report statistici filtrando per API implementata. La funzionalità è utile in presenza di molteplici erogazioni o fruizioni che implementano la stessa API, per ottenere un report che non distingua per la singola erogazione o fruizione ma li raggruppi per API implementata.

• Le transazioni visualizzate nello storico riportano anche il codice http oltre all'esito della transazione. È adesso inoltre possibile effettuare ricerche per codice http.

• La sezione 'Reportistica - Configurazione API' consente adesso di filtrare per tag.

• Il filtro per Tag presente nei criteri di ricerca presenta adesso solamente i tag assegnati alle API relative al Profilo di Interoperabilità selezionato.

Miglioramenti alla funzionalità di Validazione dei Contenuti

Utilizzando le proprietà dell'API è adesso possibile:

• API SOAP: disabilitare la validazione della SOAPAction;

• API REST: disabilitare o abilitare la validazione su codici http e/o content-type definiti puntualmente; è inoltre possibile disabilitare la validazione su risposte vuote e/o su risposte contenenti problem details.

Miglioramenti alla funzionalità del CORS

Nella configurazione CORS, quando viene abilitato uno o più specifiche origin, è adesso possibile indicare di autorizzare qualsiasi metodo e/o header http della richiesta, senza dover definire l'elenco dei metodi e/o header autorizzati.

Miglioramenti alla funzionalità dei Connettori

Sul connettore https è adesso possibile effettuare una configurazione che accetta qualsiasi certificato venga ritornato dal server.

È stata inoltre aggiunta la possibilità di configurare, a livello di installazione, un utilizzo di un java.security.SecureRandom con algoritmo personalizzato rispetto al default di java.

Infine la lunghezza massima di un endpoint associabile ad un connettore è adesso di 4000 caratteri.

Miglioramenti alla funzionalità di Trasformazione

È stato aggiunto nella maschera di gestione di un header o di un parametro della url un campo 'Identificazione Fallita' che consente di definire il comportamento del Gateway quando non riesce a risolvere le parti dinamiche contenute nel valore indicato:

• Termina con errore: la transazione termina con un errore che riporta la fallita risoluzione della parte dinamica indicata per il valore;
• Continua senza header: la transazione continua senza che l'header o il parametro venga aggiunto o modificato.

Miglioramenti alla funzionalità di Tracciatura su File

Aggiunte ulteriori informazioni, inerenti le comunicazioni gestite dal gateway, che possono essere riversate nei file di log associati ai topic di file trace:

• resultClass, resultClassOk, resultClassKo, resultClassFault: classe a cui appartiene l’esito della transazione tra OK, KO e FAULT;
• errorDetail: dettaglio dell’errore avvenuto durante la gestione della transazione;
• requester: rappresenta il richiedente della richiesta e assumerà la prima informazione valorizzata, trovata nella richiesta, tra tokenUsername, tokenSubject[@tokenIssuer], application, principal e tokenClientId;
• ipRequester: rappresenta l’indirizzo ip del richiedente e viene valorizzato con il forwardedIP se presente, o altrimenti con il clientIP;
• principalAuthType: tipo di autenticazione (basic/ssl/principal) con cui l’applicativo è stato autenticato;
• diagnostics e errorDiagnostics: consentono di accedere ai diagnostici emessi da GovWay durante la gestione della richiesta;
• senderId, providerId, apiId, apiInterfaceId, profileLabel: consentono di ottenere delle informazioni già accessibili in precedenza con un nuovo formato conforme al profilo di interoperabilità utilizzato.

Miglioramenti alle API di Gestione e Monitoraggio

Sono stati apportati i seguenti miglioramenti alle API di monitoraggio:

• È adesso possibile ricercare transazioni o ottenere report statistici filtrando per API implementata. La funzionalità è utile in presenza di molteplici erogazioni o fruizioni che implementano la stessa API, per ottenere un report che non distingua per la singola erogazione o fruizione ma li raggruppi per API implementata.

Sono stati apportati i seguenti miglioramenti alle API di gestione:

• Le risorse '/fruizioni/{erogatore}/{nome}/{versione}/url-invocazione' e '/erogazioni/{nome}/{versione}/url-invocazione' gestiscono adesso tutte le modalità supportate dal prodotto ('content-based', 'header-based', 'input-based', 'interface-based', 'soap-action-based', 'url-based', 'protocol-based'). È stata inoltre aggiunta la modalità 'static' utilizzabile su API soap contenente un'unica azione.

• È adesso possibile registrare le proprietà di configurazione nelle erogazioni e fruizioni anche tramite api.

Nuova funzionalità di suddivisione delle API in Canali

Aggiunta la possibilità di attivare, in una installazione composta da più nodi in Load Balancing, una suddivisione delle API tra i vari nodi utilizzando il concetto di canale, al fine di suddividere il carico tra i nodi.

Abilitando la nuova funzionalità sarà possibile assegnare uno o più canali ad ogni nodo che compone il cluster ed un canale ad ogni API. Su ogni nodo saranno autorizzate ad essere invocate solamente le API che possiedono un canale corrispondente alla configurazione del nodo.

Miglioramenti al Profilo di Interoperabilità 'Fatturazione Elettronica'

Aggiornati gli schemi xsd della fattura (versione 1.2.1) e della fattura semplificata (versione 1.0.1) come adeguamento al provvedimento del 28/02/2020 descritto in https://www.agenziaentrate.gov.it/portale/web/guest/-/provvedimento-del-28-febbraio-2020.
Gli schemi utilizzati sono quelli presenti all'interno dell'archivio zip della versione 1.6 delle specifiche tecniche (Allegato A).

Miglioramenti all'Installer

Sono stati apportati i seguenti miglioramenti all'installer binario:

• È stato aggiunto il supporto per la nuova versione dell'application server 'WildFly' 21.x.

• Le ...

GovWay v3.3.2

Nuova funzionalità di Autenticazione 'Api Key'

La nuova funzionalità consente di autenticare gli applicativi e i soggetti tramite una chiave di identificazione 'Api Key' veicolata in un header http, un parametro della url o un cookie come descritto nella specifica OAS3 API Keys.

Viene supportata anche la modalità 'App ID' che prevede oltre all'ApiKey un identificatore dell'applicazione; modalità denominata 'Multiple API Keys' nella specifica OAS3 API Keys.

È quindi possibile registrare applicativi e soggetti associandogli credenziali 'api-key'; la registrazione comporta la generazione di una chiave univoca da utilizzare per accedere all'API su GovWay.

La configurazione dell'autenticazione consente di indicare la modalità di identificazione della chiave di accesso tra header http, parametro della url e cookie (viene supportata la scelta multipla), permettendo anche di personalizzare i nomi dei parametri, rispetto a quanto indicato nella specifica OAS3 API Keys.

Miglioramenti alla funzionalità di Autenticazione

Introdotta la configurabilità del tipo di cifratura delle password utilizzato per:

• le utenze delle console di gestione e monitoraggio;

• gli applicativi e i soggetti registrati con credenziali 'http-basic'.

È stata adeguata la configurazione di default al fine di utilzzare un algoritmo di cifratura più recente: SHA-512-based Unix crypt ($6$).

Per garantire la retrocompatibilità con le utenze esistenti, la verifica delle password viene attuata anche usando il precedente algoritmo. La verifica in modalità 'backward compatibility' può essere disattivata una volta migrate tutte le password al nuovo formato di cifratura.

Miglioramenti alla API di Monitoraggio

Sono stati apportati i seguenti miglioramenti alle funzionalità di monitoraggio delle transazioni:

• Richiedente: l'informazione sul richiedente dell'operazione è stata aggiunta sia nel dettaglio di una transazione che nelle informazioni generali presenti nella lista.

• Client Id: tra le informazioni generali presenti in ogni item della lista è stato aggiunto il client-id del token OAuth2.

• Dettaglio Errore: nel dettaglio di una transazione è stato aggiunto il dettaglio dell'errore nel caso la transazione non sia completata con successo.

• Latenze: nel dettaglio di una transazione sono state riportate le informazioni già presenti nella lista riguardanti la data e le latenze.

• Escludi Richieste Scartate: disabilitato come criterio di default il filtro 'Escludi Richieste Scartate'.

Miglioramenti all'Installer

Sono stati apportati i seguenti miglioramenti all'installer binario:

• È stato aggiunto il supporto per la nuova versione dell'application server 'WildFly' 20.x.

• Le password relative alle utenze delle console, indicate durante l'esecuzione dell'installer, vengono predisposte negli script SQL cifrate in SHA-512-based Unix crypt ($6$).

Bug Fix

Per la console di gestione sono stati risolti i seguenti bug:

• Introdotta una nuova modalità di gestione delle operazioni di delete ed export attraverso l'utilizzo di una form con method POST al posto dell'invocazione di una GET. La nuova modalità consente di evitare il formarsi di una url eccessivamente lunga che poteva essere bloccata dai frontend http.

Per la API di configurazione sono stati risolti i seguenti bug:

• Corretto http status, da 204 a 201, restituito in caso di operazione effettuata con successo per le risorse:

  • POST /erogazioni/{nome}/{versione}/gruppi/{nome_gruppo}/azioni
  • POST /fruizioni/{erogatore}/{nome}/{versione}/gruppi/{nome_gruppo}/azioni

GovWay v3.3.1

Nuova Gestione degli Errori generati da GovWay

Sono state completamente riviste le informazioni di errore ritornate al client, in seguito ad anomalie rilevate da GovWay nella gestione della richiesta o della risposta.

Oltre agli errori già previsti nelle interfacce dell'API, gli applicativi client possono ricevere due tipi di errori generati direttamente da GovWay:

• Errori Client: identificabili da un codice http 4xx su API REST o da un fault code 'Client' su API SOAP. Indicano che GovWay ha rilevato problemi nella richiesta effettuata dal client (es. errore autenticazione, autorizzazione, validazione contenuti...).

• Errori Server: identificabili dai codici http 502, 503 e 504 per le API REST o da un fault code 'Server' generato dal Gateway e restituito con codice http 500 per le API SOAP.

La codifica degli errori prodotta dal Gateway permette alle applicazioni client di discriminare tra errori causati da una richiesta errata, per i quali è quindi necessario intervenire sull'applicazione client prima di effettuare nuovi invii, ed errori dovuti allo stato dei servizi invocati, per i quali è invece possibile continuare ad effettuare la richiesta.

Per ciascun errore GovWay riporta le seguenti informazioni:

• Un codice http su API REST o un fault code su API SOAP.
• Un codice di errore, indicato nell'header http 'GovWay-Transaction-ErrorType', che riporta l'errore rilevato dal gateway (es. AuthenticationRequired, TokenExpired, InvalidRequestContent ...).
• Un identificativo di transazione, indicato nell'header http 'GovWay-Transaction-ID', che identifica la transazione in errore, utile principalmente per indagini diagnostiche.
• Un payload http, contenente maggiori dettagli sull'errore, opportunamente codificato per API REST (Problem Details - RFC 7807) o SOAP (Fault).

Nella configurazione di default di GovWay, gli errori restituiti ai client non contengono dettagli che possano causare disclosure di informazioni relative al dominio interno. In alcuni casi, per facilitare il supporto alla risoluzione di problemi, è comunque possibile abilitare la generazione di codici più specifici di errore ritornati al client nell'header http 'GovWay-Transaction-ErrorStatus'.

Nuova funzionalità di Tracciatura su File

La nuova funzionalità consente il tracciamento su file di tutte le informazioni relative alle comunicazioni gestite da GovWay.
Il successivo processamento del file da strumenti esterni (es. FileBeat) abilità così una facile integrazione con sistemi di tracciamento esterni (es. Logstash, Kafka, ...).

La funzionalità consente una completa personalizzazione delle informazioni da riportare su file di log, permettendo anche di definirne il formato e l'ordine in cui vengono salvate. È inoltre possibile suddividere le informazioni in più file di log in modo da facilitare l'invio di informazioni selezionate a destinazioni diverse.

Nuova funzionalità Gestione Proxy

Permette di gestire correttamente le situazioni in cui le comunicazioni tra GovWay e l'endpoint destinatario siano mediate dalla presenza di un proxy.

Nei casi più comuni si tratta di un "forward proxy". In questi casi l'indirizzo del proxy può essere censito sul connettore dell'Erogazione.

In scenari più complessi possono essere presenti reverse proxy che intervengono nella gestione delle connessioni https, utilizzando certificati client e/o trustStore differenti per diversi contesti applicativi.
In queste situazioni l'endpoint indicato nella configurazione del connettore su GovWay non è l'indirizzo remoto dell'applicativo ma bensì l'indirizzo del reverse proxy il quale a sua volta si occuperà di inoltrare la richiesta agli indirizzi a lui noti.

In questa situazione, è necessario configurare gli endpoint delle API sia su GovWay (indirizzo del reverse proxy), che sul reverse proxy (indirizzo dell'Erogatore finale)

Per semplificare la gestione di questo scenario architetturale, dalla versione 3.3.1 GovWay può passare l'indirizzo remoto dell'applicativo al proxy tramite un header HTTP o un parametro della url. In questo modo il censimento degli applicativi viene effettuato esclusivamente su GovWay.

Miglioramenti al Profilo di Interoperabilità ModI PA

È adesso possibile estendere il profilo di sicurezza messaggio IDAR03/IDAS03 in modo che il token di sicurezza ModI PA contenga:

• Digest Richiesta: nel token di sicurezza della risposta viene incluso il digest della richiesta. La funzionalità consente di implementare la soluzione per la non ripudiabilità della trasmissione come suggerito nelle linee guida di interoperabilità (punto D): https://docs.italia.it/italia/piano-triennale-ict/lg-modellointeroperabilita-docs/it/bozza/doc/doc_04/soluzioni-di-sicurezza.html#soluzioni-per-la-non-ripudiabilita-della-trasmissione.

• Informazioni Utente: le informazioni sull’utente che ha effettuato la richiesta.

Miglioramenti alle Console

Sono stati apportati i seguenti miglioramenti:

• Ricerca nelle liste a tendina: aggiunta la possibilità di selezionare incrementalmente nelle liste a tendina, tramite digitazione di caratteri.

• Highlight: aggiunto il supporto dell'highlight della keyword di ricerca effettuata sia all'interno delle liste che nei campi con funzionalità di 'autocomplete'.

Relativamente alla sola console di gestione:

• Risorse REST con qualsiasi path: aggiunta la possibilità di registrare manualmente risorse in API REST con HttpMethod definito e Path Qualsiasi.

• Modifica Risorsa: è stata aggiunta la possibilità di accedere al dettaglio di una risorsa, dall'elenco presente in una API, cliccando anche sul metodo http.

• Modifica Nome Applicativo: aggiunta la possibilità di modificare il nome di un applicativo precedentemente registrato.

• Modifica API di una Erogazione/Fruizione: aggiunta la possibilità di modificare l'API implementata in una erogazione o fruizione.

• Sospensione API: la sospensione di una API (erogazione/fruizione), o la successiva riattivazione, non necessita più un'operazione di reset delle cache. L'operazione effettuata tramite console è immediatamente attiva.

Relativamente alla sola console di monitoraggio

• Ricerca per ID Transazione: è adesso il primo criterio di ricerca per identificativo

• Pie Chart: nei report a torta, sulla destra di ogni voce presente nella legenda viene adesso riportato anche il numero di record oltra la %.

• Distribuzione Temporale: aggiunta la possibilità di personalizzare il numero di label da visualizzare sull'asse X nei report con distribuzione temporale.

• Nuovi esiti associati alle Transazioni:

  • 'Errore ModI PA': gli errori generati durante la validazione 'ModI PA' vengono adesso classificati con un esito dedicato;
  • 'Richiesta o Risposta già Elaborata': i nuovi esiti sono associati a transazioni riguadanti richieste o risposte duplicate.

• Escludi Richieste Scartate: il comportamento di default utilizzato nella sezione Transazioni e Statistiche può essere modificato tramite la proprietà 'transazioni.escludiRichiesteScartate.defaultValue' nel file di configurazione esterno '/etc/govway/monitor_local.properties'.

• Volume di Traffico Iniziale: il grafico che fornisce il volume di traffico complessivo, disponibile una volta collegati alla console, è adesso configurabile per restituire il volume complessivo di tutti i Profili di Interoperabilità abilitati sul gateway.

Miglioramenti alla funzionalità di Validazione dei Contenuti

• Nuovo Engine: la validazione dei contenuti, tramite interfaccia OpenAPI 3, utilizza adesso la libreria openapi4j (https://openapi4j.github.io/openapi4j/) che consente di validare correttamente messaggi definiti tramite strutture 'oneOf' con discriminator.

• Validazione solo per la Richiesta: la validazione è adesso "disattivabile" sulla fase di richiesta o risposta utilizzando le proprietà dell'API.

Miglioramenti alla funzionalità Importa e Esporta

Nella funzionalità 'Importa' della console è adesso possibile selezionare puntualmente se importare o meno nel registro di GovWay eventuali configurazioni o policy globali (Token, RateLimiting) presenti all'interno dell'archivio.

Anche per la funzionalità 'Esporta' è possibile indicare se includere nell'archivio esportato le policy globali riferite.

Miglioramenti alla funzionalità 'Header di Integrazione'

Aggiunte nuove modalità di interscambio delle informazioni che consentono di definire tramite un template "Freemarker" o "Velocity" come le informazioni di integrazione siano inserite nel messaggio inoltrato al backend (richiesta) o restituito al client (risposta).

Miglioramenti all'Installer

Aggiunto il supporto per la nuova versione dell'application server 'WildFly' 19.x

Bug Fix

Sono stati risolti i seguenti bug:

• Nella funzionalità di tracciamento con correlazione applicativa è adesso possibile definire regole multiple di correlazione anche per i messaggi JSON e non più solamente per messaggi XML. L'applicabilità di una regola è verificabile tramite l'utilizzo di un'espressione JSONPath.

• Le richieste 'OPTIONS', identificate tramite una risorsa definita nell'API con HttpMethod 'Qualsiasi', vengono adesso gestite come 'Request Preflight' se il CORS è abilitato nell'API.

• Gli header HTTP di integrazione specifici di un Profilo di Interoperabilità (es. Fatturazione Elettronica) non venivano gestiti correttamente in caso di attivazione dei 'metadati' di integrazione 'backward compatibility' il cui scopo è quello di produrre header di integrazione uguali a quelli generati da 'OpenSPCoop2' (es. x-openspcoop2-trasporto). Il problema è stato risolto e adesso tutti gli header generati sono stati allineati per essere retrocompatibili (es. X-SDI-*).

• L'accesso al database è stato ottimizzato per i seguenti casi:

  • Registrazione delle credenziali (trasporto, token) e dei tags/eventi nella t...

GovWay v3.3.0

Nuova funzionalità di registrazione di un Applicativo Server

Gli applicativi registrati su GovWay, dalla versione 3.3.0, possono essere di due tipi:

• Client: si tratta degli applicativi presenti anche nelle precedenti versioni, censiti allo scopo di identificarli ed autorizzarli durante l'invocazione di erogazioni o fruizioni di API;

• Server: un nuovo tipo di applicativo che consente di censire una applicazione di backend alla quale associare quelle informazioni tipicamente indicate sinora nella sezione 'Connettore' dell'erogazione della API (endpoint, credenziali, ...). In una erogazione è così possibile riferire un applicativo server già registrato come modalità alternativa a quella di indicare esplicitamente tutte le informazioni richieste.

Nuova funzionalità di Load Balancer

Per le erogazioni di API è possibile definire connettori multipli con finalità di bilanciamento delle richieste in arrivo.
Vengono forniti differenti tipi di bilanciamento del carico:

• Round Robin: le richieste vengono distribuite in ordine tra i connettori registrati;

• Weight Round Robin: rispetto al Round Robin consente di riequilibrare eventuali server eterogenei tramite una distribuzione bilanciata rispetto al peso associato ad ogni connettore;

• Random: le richieste vengono distribuite casualmente tra i connettori registrati;

• Weight Random: rispetto al Random si ha una distribuzione casuale che considerà però il peso associato ad ogni connettore;

• Source IP hash: combina l'indirizzo IP del client e l'eventuale indirizzo IP portato nell'header 'Forwarded-For' per generare una chiave hash che viene designata per un connettore specifico;

• Least Connections: la richiesta viene indirizzata verso il connettore che ha il numero minimo di connessioni attive.

La configurazione permette anche di abilitare una sessione sticky in modo che tutte le richieste che presentano lo stesso id di sessione vengano servite tramite lo stesso connettore. Se l'identificativo di sessione si riferisce ad una nuova sessione, viene selezionato un connettore rispetto alla strategia indicata. L'identificativo di sessione utilizzato è individuabile tramite una delle seguenti modalità:

• Cookie: nome di un cookie;

• Header HTTP: nome di un header http;

• Url di Invocazione: espressione regolare applicata sulla url di invocazione;

• Parametro della Url: nome del parametro presente nella url di invocazione;

• Contenuto: espressione (xPath o jsonPath) utilizzata per estrarre un identificativo dal body della richiesta;

• Client IP: indirizzo IP del client;

• X-Forwared-For: header http appartenente alla classe di header 'Forwarded-For';

• Template: l'identificativo di sessione è il risultato dell'istanziazione del template fornito rispetto ai dati della richiesta;

• Freemarker Template: l'identificativo di sessione è ottenuto tramite il processamento di un Freemarker Template;

• Velocity Template: l'identificativo di sessione è ottenuto tramite il processamento di un Velocity Template;

È infine possibile attivare un 'Passive Health Check' che verifica la connettività verso i connettori configurati. Un utilizzo di un connettore che provoca un errore di connettività comporta la sua esclusione dal pool dei connettori utilizzabili per un intervallo di tempo configurabile.

Nuova funzionalità di Consegna Condizionale

Per le erogazioni di API è possibile definire connettori diversi, selezionati dinamicamente al verificarsi di specifiche condizioni.

Il connettore da utilizzare può essere selezionato in base al nome o a un filtro associato al connettore stesso. Il nome o il valore del filtro può essere estratto dalla richiesta attraverso una delle seguenti modalità:

• Header HTTP: nome di un header http;

• Url di Invocazione: espressione regolare applicata sulla url di invocazione;

• Parametro della Url: nome del parametro presente nella url di invocazione;

• SOAPAction: individua una operazione SOAP;

• Contenuto: espressione (xPath o jsonPath) utilizzata per estrarre un identificativo dal body della richiesta;

• Client IP: indirizzo IP del client;

• X-Forwared-For: header http appartenente alla classe di header 'Forwarded-For';

• Template: l'identificativo di sessione è il risultato dell'istanziazione del template fornito rispetto ai dati della richiesta;

• Freemarker Template: l'identificativo di sessione è ottenuto tramite il processamento di un Freemarker Template;

• Velocity Template: l'identificativo di sessione è ottenuto tramite il processamento di un Velocity Template;

È infine possibile configurare l'erogazione per utilizzare uno specifico connettore di default nel caso la condizione non permetta di identificare alcun connettore all'interno del pool, o in alternativa per restituire un errore.

Miglioramenti alla Console di Monitoraggio

Sono stati apportati i seguenti miglioramenti:

• Restyling grafico dello storico delle Transazioni: le informazioni sulle transazioni vengono riportate tramite una nuova veste grafica, con un approccio non più tabellare ma orientato all'ottimizzazione degli spazi e del posizionamento delle informazioni di interesse per l'operatore. È stata inoltre rivista anche la maschera di dettaglio di una transazione al fine di suddividere in maniera più razionale le numerose informazioni presenti.

• Nuovi esiti associati alle Transazioni:

  • Token non Presente: la richiesta non presenta un token;
  • Autenticazione Token Fallita: nel token ricevuto non sono presenti dei claim configurati come obbligatori per l'accesso alla API;
  • API non Individuata: la richiesta non indirizza una API registrata sul Gateway;
  • Operazione non Individuata: la richiesta non indirizza un'operazione prevista sulla API invocata.

• Nuovi criteri di ricerca delle Transazioni basate sugli esiti: sia le ricerche nello storico che le informazioni statistiche possono adesso essere ricercate per due nuovi raggruppamenti degli esiti:

  • Errori di Consegna: in questo gruppo sono collezionate tutte le transazioni con esiti che individuano un errore generato dal backend applicativo (Fault Applicativi e/o codici di ritorno 4xx e 5xx) o un errore di connettività verso il backend.
  • Richieste Scartate: in questo gruppo sono collezionate tutte le transazioni con esiti che riguardano richieste di erogazione o fruizione malformate (es. api non individuate, operazioni non individuate, errori di autenticazione ...)

  Inoltre per gli altri criteri di ricerca è sempre possibile indicare se le richieste scartate devono essere prese in considerazione o meno; per default le richieste scartate non vengono considerate ai fini del risultato della ricerca.

• Numero di Risultati: nello storico delle transazioni è adesso possibile indicare il numero di risultati della ricerca che si desidera ottenere (default: 25).

Java 11, A.S. e Librerie 3Parti

Dalla versione 3.3.0, GovWay introduce nuovi vincoli sulle versioni minime dei prodotti parte dello stack tecnologico utilizzato:

• La versione 11 di Java, una release di tipo LTS (Long-Term Support).

• Application Server: v18 per WildFly e v9 per Apache Tomcat.

Sono state inoltre aggiornate alle versioni più recenti tutte le librerie 3parti utilizzate.

GovWay v3.3.0.rc1

Nuova funzionalità di registrazione di un Applicativo Server

Gli applicativi registrati su GovWay, dalla versione 3.3.0, possono essere di due tipi:

• Client: si tratta degli applicativi presenti anche nelle precedenti versioni, censiti allo scopo di identificarli ed autorizzarli durante l'invocazione di erogazioni o fruizioni di API;

• Server: un nuovo tipo di applicativo che consente di censire una applicazione di backend alla quale associare quelle informazioni tipicamente indicate sinora nella sezione 'Connettore' dell'erogazione della API (endpoint, credenziali, ...). In una erogazione è così possibile riferire un applicativo server già registrato come modalità alternativa a quella di indicare esplicitamente tutte le informazioni richieste.

Nuova funzionalità di Load Balancer

Per le erogazioni di API è possibile definire connettori multipli con finalità di bilanciamento delle richieste in arrivo.
Vengono forniti differenti tipi di bilanciamento del carico:

• Round Robin: le richieste vengono distribuite in ordine tra i connettori registrati;

• Weight Round Robin: rispetto al Round Robin consente di riequilibrare eventuali server eterogenei tramite una distribuzione bilanciata rispetto al peso associato ad ogni connettore;

• Random: le richieste vengono distribuite casualmente tra i connettori registrati;

• Weight Random: rispetto al Random si ha una distribuzione casuale che considerà però il peso associato ad ogni connettore;

• Source IP hash: combina l'indirizzo IP del client e l'eventuale indirizzo IP portato nell'header 'Forwarded-For' per generare una chiave hash che viene designata per un connettore specifico;

• Least Connections: la richiesta viene indirizzata verso il connettore che ha il numero minimo di connessioni attive.

La configurazione permette anche di abilitare una sessione sticky in modo che tutte le richieste che presentano lo stesso id di sessione vengano servite tramite lo stesso connettore. Se l'identificativo di sessione si riferisce ad una nuova sessione, viene selezionato un connettore rispetto alla strategia indicata. L'identificativo di sessione utilizzato è individuabile tramite una delle seguenti modalità:

• Cookie: nome di un cookie;

• Header HTTP: nome di un header http;

• Url di Invocazione: espressione regolare applicata sulla url di invocazione;

• Parametro della Url: nome del parametro presente nella url di invocazione;

• Contenuto: espressione (xPath o jsonPath) utilizzata per estrarre un identificativo dal body della richiesta;

• Client IP: indirizzo IP del client;

• X-Forwared-For: header http appartenente alla classe di header 'Forwarded-For';

• Template: l'identificativo di sessione è il risultato dell'istanziazione del template fornito rispetto ai dati della richiesta;

• Freemarker Template: l'identificativo di sessione è ottenuto tramite il processamento di un Freemarker Template;

• Velocity Template: l'identificativo di sessione è ottenuto tramite il processamento di un Velocity Template;

È infine possibile attivare un 'Passive Health Check' che verifica la connettività verso i connettori configurati. Un utilizzo di un connettore che provoca un errore di connettività comporta la sua esclusione dal pool dei connettori utilizzabili per un intervallo di tempo configurabile.

Nuova funzionalità di Consegna Condizionale

Per le erogazioni di API è possibile definire connettori diversi, selezionati dinamicamente al verificarsi di specifiche condizioni.

Il connettore da utilizzare può essere selezionato in base al nome o a un filtro associato al connettore stesso. Il nome o il valore del filtro può essere estratto dalla richiesta attraverso una delle seguenti modalità:

• Header HTTP: nome di un header http;

• Url di Invocazione: espressione regolare applicata sulla url di invocazione;

• Parametro della Url: nome del parametro presente nella url di invocazione;

• SOAPAction: individua una operazione SOAP;

• Contenuto: espressione (xPath o jsonPath) utilizzata per estrarre un identificativo dal body della richiesta;

• Client IP: indirizzo IP del client;

• X-Forwared-For: header http appartenente alla classe di header 'Forwarded-For';

• Template: l'identificativo di sessione è il risultato dell'istanziazione del template fornito rispetto ai dati della richiesta;

• Freemarker Template: l'identificativo di sessione è ottenuto tramite il processamento di un Freemarker Template;

• Velocity Template: l'identificativo di sessione è ottenuto tramite il processamento di un Velocity Template;

È infine possibile configurare l'erogazione per utilizzare uno specifico connettore di default nel caso la condizione non permetta di identificare alcun connettore all'interno del pool, o in alternativa per restituire un errore.

Miglioramenti alla Console di Monitoraggio

Sono stati apportati i seguenti miglioramenti:

• Restyling grafico dello storico delle Transazioni: le informazioni sulle transazioni vengono riportate tramite una nuova veste grafica, con un approccio non più tabellare ma orientato all'ottimizzazione degli spazi e del posizionamento delle informazioni di interesse per l'operatore. È stata inoltre rivista anche la maschera di dettaglio di una transazione al fine di suddividere in maniera più razionale le numerose informazioni presenti.

• Nuovi esiti associati alle Transazioni:

  • Token non Presente: la richiesta non presenta un token;
  • Autenticazione Token Fallita: nel token ricevuto non sono presenti dei claim configurati come obbligatori per l'accesso alla API;
  • API non Individuata: la richiesta non indirizza una API registrata sul Gateway;
  • Operazione non Individuata: la richiesta non indirizza un'operazione prevista sulla API invocata.

• Nuovi criteri di ricerca delle Transazioni basate sugli esiti: sia le ricerche nello storico che le informazioni statistiche possono adesso essere ricercate per due nuovi raggruppamenti degli esiti:

  • Errori di Consegna: in questo gruppo sono collezionate tutte le transazioni con esiti che individuano un errore generato dal backend applicativo (Fault Applicativi e/o codici di ritorno 4xx e 5xx) o un errore di connettività verso il backend.
  • Richieste Scartate: in questo gruppo sono collezionate tutte le transazioni con esiti che riguardano richieste di erogazione o fruizione malformate (es. api non individuate, operazioni non individuate, errori di autenticazione ...)

  Inoltre per gli altri criteri di ricerca è sempre possibile indicare se le richieste scartate devono essere prese in considerazione o meno; per default le richieste scartate non vengono considerate ai fini del risultato della ricerca.

• Numero di Risultati: nello storico delle transazioni è adesso possibile indicare il numero di risultati della ricerca che si desidera ottenere (default: 25).

Java 11, A.S. e Librerie 3Parti

Dalla versione 3.3.0, GovWay introduce nuovi vincoli sulle versioni minime dei prodotti parte dello stack tecnologico utilizzato:

• La versione 11 di Java, una release di tipo LTS (Long-Term Support).

• Application Server: v18 per WildFly e v9 per Apache Tomcat.

Sono state inoltre aggiornate alle versioni più recenti tutte le librerie 3parti utilizzate.

GovWay v3.2.2

Miglioramenti alla Console di Gestione

Sono state introdotte le seguenti nuove funzionalità:

• Nuova Versione API: nel dettaglio di una API è adesso disponibile il pulsante di creazione di una nuova versione dell'API. Durante la creazione della nuova versione è possibile scegliere se fornire una nuova specifica dell'interfaccia o ereditarla (insieme alle azioni/risorse e agli allegati) dalla precedente.

• Generazione http-basic password per un Applicativo/Soggetto: in caso di registrazione di un applicativo o di un soggetto, con autenticazione di tipo http-basic, è ora presente un pulsante per il fill del campo password con una password generata random in accordo a criteri minimi di qualità. È stato inoltre aggiunto un vincolo di univocità sull'username associato ad un applicativo o ad soggetto.

• Trasformazione del Contesto di Invocazione: per una API di tipo REST, all'interno della trasformazione della richiesta nella sezione 'trasporto', è adesso possibile modificare sia il metodo http che il path concatenato alla base url utilizzata per invocare l'applicativo di backend.

Miglioramenti all'Installer

Sono stati apportati i seguenti miglioramenti all'installer binario:

• È stato aggiunto il supporto per la nuova versione dell'application server 'WildFly' 18.x

• Le directory 'controlloTraffico', 'dumpNonRealTime', 'resources' e 'attachments' vengono adesso configurate per essere generate nella logDir e non più nella workDir

Bug Fix

Sono stati risolti i seguenti bug:

• Corretta sezione 'Configurazione in Load Balancing' della Guida di Installazione che presentava nomi di proprietà errati.

• Risolti alcuni problemi presenti nella diagnostica emessa per le funzionalità di trasformazione e gestione dei token.

Per la console di gestione sono stati risolti i seguenti bug:

• Non era possibile eliminare un'azione da una API di tipo SOAP se esisteva un'azione con lo stesso nome in un'altra API.

• La console produceva un errore non gestito al momento di registrare una nuova regola di Proxy Pass. Il problema sussisteva solamente su nuove installazioni dove non era mai stato effettuato il salvataggio della configurazione.

Sulla console di monitoraggio sono stati risolti i seguenti bug:

• Nella ricerca transazioni, in ciascuna delle ricerche per mittente (Token Info, Soggetto ecc..), quando veniva cambiata la Tipologia (Fruzione,Erogazione,Qualsiasi), scomparivano gli input sotto la sezione "Dati Mittente".

• Sia per la ricerca di transazioni che per la generazione di report statistici, quando il valore della lista 'Tipologia' era indefinito, non veniva visualizzato il campo per la scelta del Soggetto Remoto.

Per le API di configurazione e monitoraggio sono stati risolti i seguenti bug:

• Le liste vengono adesso correttamente valorizzate con gli elementi 'next', 'prev', 'last' e 'first' attraverso url relative che preservano i parametri della query e non contengono la base url.

• Migliorate validazioni degli oggetti oneOf dove è stata agganciata una validazione sintattica degli oggetti forniti rispetto al parametro discriminator.

• Per l'API di monitoraggio:

  • Nei metodi GET è adesso possibile indicare il soggetto erogatore di una api.

  • Nei metodi POST è adesso possibile indicare, con tipologia di ricerca qualsiasi, il soggetto remoto e/o il soggetto erogatore di una api.

  • Nell'interfaccia yaml sono stati aggiunti i criteri di obbligatorietà per i campi 'data_inizio' e 'data_fine' dell'oggetto FiltroTemporale e per il campo tipo dell'oggetto FiltroEsito. Inoltre il FiltroMittenteErogazioneDistribuzioneSoggettoRemoto è stato modificato per utilizzare una enumeration personalizzata, relativamente al tipo di ricerca, che non contiene il soggetto.

• Nella API di configurazione, l'opzione 'forward' relativa all'autenticazione basic o principal di un applicativo/soggetto veniva salvata con valore invertito.