API Gateway per la Pubblica Amministrazione italiana
Sono stati apportati i seguenti miglioramenti alla gestione dei pattern 'AUDIT_REST_01' e 'AUDIT_REST_02':
aggiunta la possibilità di definire dei criteri di validazioni sui claim attesi all'interno del token di audit; i criteri associabili ad ogni specifico claim sono:
nella definizione delle informazioni personalizzate da includere nel token di AUDIT è adesso possibile indicare per ogni singolo claim se l'informazione veicolata sia riutilizzabile o meno su differenti chiamate; l'intero token di audit verrà salvato in cache e riutilizzato su differenti chiamate solo se tutti i claim inseriti all'interno del token risultano configurati come riutilizzabili;
attivando una configurazione opzionale per il token di audit, l'impostazione veniva ignorata e il token veniva obbligatoriamente richiesto; l'anomalia è stata risolta.
Sono stati apportati i seguenti miglioramenti alla funzionalità di integrazione con la PDND:
è stato rivisto il concetto di richiedente di una richiesta di servizio al fine di considerare anche il nome dell'organizzazione recuperata tramite le API PDND, in modo da visualizzarla al posto del clientId durante la consultazione dello storico delle transazioni;
sono stati introdotti i seguenti miglioramenti alla console e alle API di monitoraggio per utilizzare i dati individuati tramite le API PDND:
tramite la console di gestione è adesso possibile verificare o eliminare i dati presenti nella cache locale contenente le chiavi pubbliche (JWK) e le informazioni sui client raccolte tramite le API PDND;
nella configurazione che consente l'invocazione delle API PDND è adesso possibile:
Sono infine stati apportati i seguenti miglioramenti:
aggiunto supporto per uno scenario di fruizione ModI in cui sia necessario utilizzare il materiale crittografico definito nella token policy per firmare i token di AUDIT e di INTEGRITY;
la validazione dei token 'ModI' non supportava token contenenti claim 'aud' definiti come stringhe di array; è stato aggiunto il supporto in modo da rispettare entrambe le modalità (array of case-sensitive strings or single case-sensitive string) indicate nel RFC 'https://datatracker.ietf.org/doc/html/rfc7519.html#section-4.1.3';
la produzione e la validazione dell'header di integrità 'Custom-JWT-Signature' è adesso attivabile anche per metodi senza payload.
Sono stati apportati i seguenti miglioramenti:
anche per le richieste contenenti credenziali non valide, token scaduti o non autorizzati vengono adesso registrate:
sono stati aggiunti nuovi esiti per le transazioni:
le classi di appartenenza degli esiti sono state riviste al fine di includere il nuovo esito 'Request Read Timeout' e l'esito 'Connessione Client Interrotta' in una nuova classe 'Errore Client Indisponibile';
i nuovi esiti relativi a timeout concorrono alla generazione di eventi che consentono all'operatore di indivuare l'occorrenza di errori di timeout senza dove effettuare ricerche puntuali nello storico delle transazioni;
le informazioni raccolte tramite le API PDND sono state aggiunte alla base dati di tracciamento in modo da consentirne l'estrazione tramite viste personalizzate;
nella funzionalità 'fileTrace' è adesso possibile accedere alle seguenti informazioni ModI:
Sono state modificate le seguenti logiche di gestione.
Una richiesta non intercettata da nessuna regola di correlazione applicativa, fino alla versione 3.3.13.p1, terminava con l’errore:
"Identificativo di correlazione applicativa non identificato; nessun elemento tra quelli di correlazione definiti è presente nel body".
È stato modificato il default in modo da accettare la richiesta. Il precedente comportamento è ripristinabile agendo sulle proprietà della singola fruizione o erogazione di API.
Una correlazione applicativa configurata con una modalità d'identificazione basata su header HTTP e un comportamento in caso di identificazione fallita uguale al valore 'accetta', provocava la terminazione con errore della transazione se la richiesta non presentava l'header HTTP configurato. L'errore riportato era il seguente:
"Identificativo di correlazione applicativa non identificato; nessun elemento tra quelli di correlazione definiti è presente nel body".
L'anomalia si presentava anche per altre modalità di identificazione nel caso in cui l'identificativo estratto risultasse null o una stringa vuota. È stato modificato il comportamento di default del gateway in modo da considerare entrambi i casi come una estrazione di correlazione applicativa fallita. Il precedente comportamento di accettare identificativi null o stringhe vuote è ripristinabile agendo sulle proprietà della singola fruizione o erogazione di API.
In una token policy di validazione, per un token JWS è adesso possibile aggiungere criteri di validazione dei 'typ', 'cty' e 'alg' presenti nell'header.
È inoltre stata differenziata la cache che conserva i dati recuperati dalle Attribute Authority rispetto alla cache che conserva i token.
Viene adesso consentito l'utilizzo di valori dinamici anche sul flusso di risposta per quanto concerne la funzionalità di sicurezza messaggio.
Inoltre per la funzionalità 'WS-Security Username Token' è adesso possibile definire una mappa di credenziali attese.
Su ogni oggetto del registro è adesso possibile indicare una descrizione contenente fino a 4000 caratteri.
Inoltre sono adesso consultabili le informazioni su chi e quando ha creato o modificato un oggetto tramite la nuova voce 'Proprietà' utilizzabile tramite il menù "tre puntini" presente sia nell'elenco che nel dettaglio di un oggetto.
Infine sono state riviste le schede di visualizzazione dei dettagli di una API, di una erogazione o fruizione e di un gruppo di configurazioni per i seguenti aspetti:
Sono stati apportati i seguenti miglioramenti alle funzionalità di reportistica:
nella funzionalità "Configurazione API" è adesso possibile esportare il report oltre che nel formato 'csv' anche nel formato 'xls';
nella funzionalità "Analisi Statistica" è adesso possibile produrre anche una distribuzione statistica in 3 dimensioni: criterio di distribuzione, data e valore.
Sono stati apportati i seguenti miglioramenti all'installer binario:
aggiunti script di svecchiamento delle tracce per tipo di database sqlserver;
eliminata la generazione dell'archivio 'govwaySec' prodotto per default tra gli archivi generati per l'application server WildFly; l'archivio è comunque generabile abilitando l'opzione specifica disponibile in modalità avanzata;
gli artefatti prodotti dall'installer in caso di scelta del profilo di interoperabiltà 'eDelivery' presentavano i seguenti errori:
La lista completa dei bug risolti è disponibile in https://govway.readthedocs.io/it/latest/releaseNotes/3.3.14/bug.html
Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
CVE-2023-51074: aggiornata libreria 'com.jayway.jsonpath:json-path' alla versione 2.9.0;
CVE-2023-45860: aggiornata libreria 'com.hazelcast:hazelcast' alla versione 5.3.5;
CVE-2023-44483: aggiornata libreria 'org.apache.santuario:xmlsec' alla versione 2.3.4;
CVE-2023-5072: aggiornata libreria 'org.json:json' alla versione 20231013;
CVE-2023-4586: aggiornata libreria 'io.netty:*' alla versione 4.1.100.Final, libreria 'org.redisson:redisson' alla versione 3.23.5 e libreria 'org.jboss.marshalling:*' alla versione 2.1.3.SP1
CVE-2023-34042: aggiornata libreria 'org.springframework.security:*' alla versione 5.8.7;
CVE-2023-4759: aggiornata libreria 'org.eclipse.jgit:org.eclipse.jgit' alla versione 6.7.0.202309050840-r;
CVE-2023-40167: aggiornata libreria 'org.eclipse.jetty:*' alla versione 10.0.16.
Sono stati risolti i seguenti bug:
le richieste contenenti metodi http 'PATCH', 'LINK' e 'UNLINK' venivano inoltrate al backend erroneamente come metodo POST se la connessione era https;
non venivano utilizzati i tempi di connection e read timeout impostati a livello globale; l'anomalia è stata risolta e nell'occasione sono stati rivisti i tempi di default utilizzati a livello globale per una nuova installazione:
risolta anomalia che si verificava in alcuni casi limite durante il tracciamento delle fruizioni di API con negoziazione token; l'errore segnalato nei log era: "PostOutResponseHandler [transazioni]Errore durante la scrittura della transazione sul database (Lettura dati Transazione): Caused by: java.util.ConcurrentModificationException ... at org.openspcoop2.pdd.core.token.TokenUtilities.replaceTokenInMap(TokenUtilities.java)".
Sono stati risolti i seguenti bug relativi al profilo di interoperabilità "ModI":
in una fruizione ModI di una API definita tramite i pattern 'ID_AUTH_REST via PDND' e 'AUDIT_REST_01', se la fruizione risultava configurata per utilizzare un keystore definito nell'applicativo e quest'ultimo non veniva identificato durante la gestione della richiesta, GovWay emetteva un diagnostico malformato: "Il profilo di sicurezza richiesto 'null' richiede l'identificazione di un applicativo";
in un contesto in cui risultava già attiva una erogazione definita senza pattern di sicurezza messaggio o con un pattern con generazione token 'Authorization ModI', se veniva modificata l'API per utilizzare un pattern con token 'Authorization PDND', la sezione controllo degli accessi dell'erogazione non consentiva di abilitare la token policy di validazione dei voucher PDND;
la creazione di una erogazione di API con pattern di sicurezza canale 'ID_AUTH_CHANNEL_02' veniva effettuata definendo un controllo accessi non corretto poichè l'autenticazione canale veniva configurata come opzionale;
in un API definita con un pattern di sicurezza messaggio con generazione token 'Authorization ModI' e con voce 'Header HTTP del Token' impostata a 'Custom-JWT-Signature', se veniva modificata la voce di generazione token in 'Authorization PDND' rimanevano inconsistenti le successive voci che consentono la configurazione dell'header custom;
la verifica dei keystore/truststore di una fruizione o erogazione, da utilizzare per i token di risposta, viene adesso effettuata solamente se l'API prevede un token di sicurezza nella risposta;
una fruizione ModI di una API definita con pattern 'ID_AUTH_REST' e 'Generazione Token via PDND' presentava le seguenti anomalie:
la verifica dei certificati non veniva effettuata: la console indicava che tutti i certificati erano validi anche quando non lo erano;
la configurazione fornita dalla funzionalità 'Visualizza dettagli della configurazione', presente nelle opzioni della fruizione, non visualizzava le informazioni corrette su eventuali keystore definiti nella fruizione stessa;
durante la registrazione di un applicativo con profilo di interoperabilità 'ModI', se nella sezione 'ModI - Sicurezza Messaggio - KeyStore' veniva effettuato con modalità 'Archivio' l'upload di un keystore pkcs12, creato importando un altro archivio pkcs12 al suo interno, si otteneva l'errore: "keystore password was incorrect". Si trattava dello stesso bug risolto nell'issue 'https://github.com/link-it/govway/issues/128' la cui risoluzione non era stata riportata nella maschera di gestione della sicurezza ModI di un applicativo.
Per la console di gestione sono stati risolti i seguenti bug:
durante la visualizzazione di una pagina, il componente "loading", che inibisce l'utilizzo della pagina stessa, terminava la sua funzione prima che il caricamento della pagina fosse completato;
la creazione di una API tramite caricamento di un'interfaccia OpenAPI contenente la definizione di un parametro di tipo 'header' falliva e dai log si poteva riscontrare il seguente errore: "Trovato parametro header 'Authorization' senza tipo";
se veniva effettuata una configurazione dei nodi in cluster suddivisi per gruppi, l'operazione "Svuota le Cache dei nodi '<nomeGruppo>'" veniva ripetuta erroneamente più volte per ogni nodo;
su una erogazione configurata per gestire gruppi di risorse differenti, in cui per ogni gruppo fosse ridefinito il connettore e attivata la consegna condizionale, il passaggio in visualizzazione tra gruppi diversi poteva mostrare dati dei connettori errati.
Per la console di monitoraggio sono stati risolti i seguenti bug:
Per le API di monitoraggio sono stati risolti i seguenti bug:
la distribuzione temporale non consentiva di ottenere report contenenti informazioni sull'occupazione della banda e sul tempo medio di risposta dei servizi;
tra le informazioni restituite per un evento non era presente la sua descrizione.
Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
CVE-2023-2976: aggiornata libreria 'com.google.guava:guava' alla versione 32.1.1-jre;
CVE-2023-34034: aggiornata libreria 'org.springframework.security:*' alla versione 5.8.5;
CVE-2023-34462: aggiornata libreria 'io.netty:*' alla versione 4.1.94.Final.
Sono stati risolti i seguenti bug:
corrette le seguenti anomalie relative al profilo di interoperabilità 'ModI':
risultavano le stesse informazioni sulle organizzazioni prelevate dalla PDND relativamente a chiamate (clientId) differenti;
dopo un upgrade all'ultima versione 3.3.13 si otteneva l'errore "[GOVWAY-6] - EccezioneProcessamento: per abilitare la proprietà è richiesto che sia abilitata la gestione delle chiavi PDND" se il file di proprietà esterno 'govway_local.properties' non veniva aggiornato con le differenze introdotte nell'ultima versione riguardanti la gestione delle chiavi 'PDND'. La problematica è stata risolta in modo che l'errore non avvenga anche se non vengono aggiornati i file locali;
nel profilo di interoperabilità 'SPCoop' è stato rivisto l'utilizzo dell'identificativo numerico del nodo in modo da utilizzare il "padding" corretto in presenza di 2 cifre;
utilizzando la configurazione di Apache suggerita per inoltrare il certificato TLS ('RequestHeader set SSL_CLIENT_CERT "%{SSL_CLIENT_CERT}s" "expr=-n %{SSL_CLIENT_CERT}"') avviene un inoltro dell'header in una formato che non veniva supportato da GovWay: PEM su una unica linea dove i ritorni a capo venivano sostituiti da spazi. È stato aggiunto il supporto.
Sono state corrette alcune anomalie riguardanti la consegna asincrona:
i messaggi serializzati su database contenevano informazioni "inconsistenti" se utilizzati dopo un upgrade di versione di GovWay. In particolar modo l'identificativo di protocollo (trasparente, modi, spcoop...) non veniva risolto correttamente causando una mancata registrazione della diagnostica, dei messaggi e dei dati relativi alla consegna asincrona (nella transazione) per le nuove consegne effettuate con la versione del software aggiornata;
l'informazione di contesto sul nome della porta invocata non era presente in un messaggio trasformato e causava un errore simile al seguente: "Errore avvenuto durante la consegna HTTP: Errore durante la raccolta delle informazioni necessarie alla funzione di proxy pass reverse: [getPortaApplicativa]: Parametro non definito (idPA.getNome() is null)".
Per la console di gestione sono stati risolti i seguenti bug:
modificando la configurazione di una fruizione o di una erogazione (es. sicurezza messaggio) era necessario effettuare due volte l'operazione 'Rimuovi dalla Cache' per far sì che la modifica venisse effettivamente vista dal runtime;
in un ambiente multi-tenant la creazione di un applicativo con credenziali api-key, dove il soggetto di dominio interno non veniva selezionato attraverso le voci in alto a destra nella console ma utilizzando la select list presente nella form di creazione, non funzionava correttamente poichè le credenziali generate venivano assegnate al soggetto presente inizialmente nella maschera di creazione e non al soggetto successivamente selezionato;
se su una API REST venivano caricati schemi XSD, il download della 'XSD Schema Collection' produceva l'errore: "Content is not allowed in prolog.";
nella maschera di resoconto dei dati di una trasformazione della richiesta, dopo aver effettuato una operazione di salvataggio, i link sugli header http e/o sui parametri della url non riportavano il numero corretto di header/parametri precedentemente configurati e veniva sempre indicato il valore '0';
corretti alcuni errori che procuravano il fallimento dell'importazione di configurazione tramite 'wizard'.
Per le API di monitoraggio sono stati risolti i seguenti bug:
Il profilo di interoperabilità 'ModI' è stato adeguato agli aggiornamenti AGID sulle Linee Guida di Interoperabilità indicati nella determina n.128 del 23 maggio 2023.
Sono ora supportati anche i seguenti nuovi pattern di sicurezza:
L'insieme dei claim da includere nel JWT di Audit 'Agid-JWT-TrackingEvidence' è configurabile consentendo di definire insiemi differenti da associare alle API.
La validazione dei token di tipo AUDIT o INTEGRITY ricevuti può essere effettuata anche utilizzando una validazione 'PDND' configurata per prelevare la chiave pubblica del mittente tramite le API di interoperabilità esposte dalla PDND. La chiave viene poi memorizzata in una cache locale e mantenuta aggiornata tramite gli eventi, emessi dalla PDND, relativi alle chiavi prelevate.
Sono inoltre stati apportati i seguenti miglioramenti:
è stata rivista la definizione del pattern di sicurezza nella API al fine di indicare chi genera il token ID_AUTH tra il mittente e la PDND;
aggiunta possibilità di arricchire la traccia di informazioni relative al client-id presente nel token 'ID_AUTH' attraverso informazioni prelevate utilizzando le API della PDND;
nella personalizzazione dei keystore è adesso possibile utilizzare una chiave privata, protetta da password o meno, nei formati pkcs1 o pkcs8 in codifica PEM o DER;
aggiunta possibilità di utilizzare un keystore JWK sia come keystore che come truststore;
migliorata diagnostica emessa in presenza di una richiesta con pattern 'INTEGRITY_REST' che presenta l'header digest e un payload http vuoto. L'errore che veniva segnalato nel diagnostico era fuorviante poichè indicava: "Header HTTP 'digest', dichiarato tra gli header firmati, non trovato". Adesso invece l'errore riportato è il seguente: "Header HTTP 'Digest' presente in una risposta con http payload vuoto".
risolto bug di verifica audience; l'anomalia avveniva in presenza di erogazioni configurate con un valore di audience di default e operazioni suddivise in gruppi di configurazione differente. Per le operazioni associate a gruppi di configurazione diverse da quello predefinito la verifica dell'audience falliva erroneamente.
Nelle Token Policy sia di validazione che di negoziazione e negli Attribute Authority è stato aggiunto il supporto per i seguenti archivi:
'Key Pair': chiave pubblica e privata, protetta da password o meno, nei formati pkcs1 o pkcs8 in codifica PEM o DER;
'Public Key': chiave pubblica in codifica PEM o DER;
'JWK Set': l'archivio è adesso utilizzabile in tutti i contesti in cui è definibile un keystore o un truststore.
La funzionalità 'Verifica Certificati' è stata migliorata al fine di:
supportare i nuovi tipi di archivio;
aggiungere la verifica di accesso alla chiave privata tramite la password fornita per i tipi di archivio già esistenti (JKS, PKCS12, ...).
Il gestore delle credenziali, utilizzabile per l'autenticazione dei certificati client ottenuti tramite header HTTP, supporta adesso anche la decodifica HEX. È stata inoltre aggiunta la possibilità di decodificare i certificati ricevuti in qualsiasi modalità supportata, prima provando la decodifica 'urlEncoded', in caso di fallimento la decodifica 'base64' e infine la decodifica 'hex'.
È adesso possibile definire 'white-list' o 'black-list' per gli header HTTP da registrare sia a livello di singola erogazione o fruizione tramite le proprietà, sia a livello globale nel file govway_local.properties.
La funzionalità consente di specificare le liste sia sui singoli flussi (richiesta-ingresso, richiesta-uscita, risposta-ingresso, risposta-uscita) sia differenziando tra erogazione e fruizione.
Sono stati apportati i seguenti miglioramenti all'installer binario:
aggiunti script di svecchiamento delle tracce per tipo di database postgresql e oracle;
l'esecuzione in modalità testuale ('./install.sh text') rimaneva bloccata in caso di tipologia d'installazione 'Aggiornamento' durante la selezione della 'Versione Precedente'.
Inoltre la modalità "gestione dei nodi dinamica", indicata per le installazioni in cloud e selezionabile con una installazione in modalità avanzata, è stata modificata per rendere utilizzabile la soluzione anche in architetture cloud dove i nodi runtime (pod) non risultano invocabili tra di loro.
Il nome di un soggetto, escluso che per il profilo di interoperabilità SPCoop, può adesso essere definito anche tramite il carattere '-'.
Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
CVE-2023-33201: aggiornata libreria 'org.bouncycastle:*' alla versione 1.74;
CVE-2023-34411: aggiornata libreria 'com.fasterxml.woodstox:woodstox-core' alla versione 6.5.1, 'org.apache.cxf:*' alla versione 3.6.1 e 'org.ow2.asm:asm' alla versione 9.5;
CVE-2020-8908: aggiornata libreria 'com.google.guava:guava' alla versione 32.0.0-jre;
CVE-2023-33264: aggiornata libreria 'com.hazelcast:hazelcast' alla versione 5.3.0;
CVE-2023-20862: aggiornata libreria 'org.springframework.security:spring-security-*' alla versione 5.8;
CVE-2017-9096, CVE-2022-24196 e CVE-2022-24197: sostituita libreria 'com.lowagie:itext' versione 2.1.7.js7 con le librerie 'org.apache.pdfbox:*' versione 2.0.27 e 'com.github.dhorions:boxable' versione 1.7.0.
Sono stati risolti i seguenti bug:
(https://github.com/link-it/govway/issues/133) tentando di avviare la piattaforma GovWay sotto Windows si otteneva un errore causato dal mancato supporto agli attributi posix: "java.lang.UnsupportedOperationException: 'posix:permissions' not supported as initial attribute";
(https://github.com/link-it/govway/issues/128) l'accesso ad un keystore pkcs12 creato importando un archivio pkcs12 al suo interno falliva con il seguente errore: "keystore password was incorrect";
su database SQLServer veniva segnalato il seguente errore dovuto ad una colonna definita in minuscolo e riferita nella query in maiuscolo: "ERROR .... [GestoreCorrelazioneApplicativa.getCorrelazioniStoriche] errore, queryString[SELECT TOP 50 id,SCADENZA FROM CORRELAZIONE_APPLICATIVA WHERE ( ORA_REGISTRAZIONE < ? )]: Invalid column name 'ORA_REGISTRAZIONE'.";
nella configurazione di default, su API SOAP, il riconoscimento dell'operazione avviene comparando il path indicato dopo la base-url rispetto alle operazioni della API. Il riconoscimento dell'operazione basata sulla url non funzionava correttamente in presenza di una url formata da molteplici endpoint come ad esempio: "http://host/govway/ente/service/v1/azione1,http://host/govway/ente/service/v1/azione3". L'operazione che veniva erroneamente individuata era 'azione3'. La problematica risiedeva nell'espressione regolare generata per default dalla console di configurazione e associata alla funzionalità di identificazione dell'operazione, nell'esempio:
L'espressione è stata corretta in:
Per la console di gestione sono stati risolti i seguenti bug:
l'apertura di un nuovo tab tramite le breadcump rendeva la console inutilizzabile sul nuovo tab. Per provocare l'anomalia si doveva procedere come segue:
la maschera di creazione di un soggetto con profilo di interoperabiltà 'API Gateway' o 'ModI' consente adesso di crearlo con una tipologia 'Fruitore' senza dover obbligatoriamente fornire delle credenziali; lo scenario serve a definire il soggetto che verrà poi associato all'applicativo fruitore che possiede le credenziali.
In una token policy di validazione è adesso possibile definire una validazione JWT che identifica il certificato all'interno del truststore, da utilizzare per la validazione, attraverso il 'kid' presente nell'header del token.
È adesso possibile configurare GovWay per utilizzare una configurazione https differente da quella ereditata dalla jvm, oltre che tramite la configurazione specifica di un connettore https, attraverso un repository di configurazioni definite tramite file di proprietà.
Il nome e la posizione del file di proprietà è configurabile a livello di singola API.
Il nome del file indicato può contenere delle macro, risolte a runtime dal gateway, per creare dei path dinamici (es. un keystore differente per ogni applicativo).
Tra le informazioni dinamiche utilizzabili all'interno di trasformazioni è adesso possibile riferire anche l'identificativo di correlazione applicativa.
Nelle consegna di una notifica asincrona, attivando una trasformazione, è adesso possibile accedere oltre che alla richiesta e alla risposta della transazione sincrona anche al contesto di tale transazione. È stata inoltre risolta un'anomalia che provocava la mancata esecuzione di una trasformazione se, tra i criteri di applicabilità, veniva utilizzato il connettore associato all'implementazione dell'API.
Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
CVE-2023-20863: aggiornata libreria 'org.springframework:spring-expression' alla versione 5.3.27
CVE-2023-1436: aggiornata libreria 'org.codehaus.jettison:jettison' alla versione 1.5.4
CVE-2023-1370: aggiornata libreria 'net.minidev:json-smart' alla versione 2.4.10
CVE-2023-20861: aggiornata libreria 'org.springframework:spring-*' alla versione 5.3.26
CVE-2022-42003: aggiornata libreria 'com.fasterxml.jackson.core:jackson-databind' alla versione 2.14.2
Per la console di gestione sono stati risolti i seguenti bug:
l'accesso alle maschere di configurazione delle proprietà di sistema, delle regole di proxy pass, delle regole di response caching e dei canali produceva un errore inatteso;
durante l'aggiornamento dell'interfaccia OpenAPI o WSDL di una API, se l'utente decideva di annullare l'aggiornamento la console andava in errore e nel log veniva riportato un errore simile al seguente: 'Parametro [_csrf] Duplicato';
caricando un'interfaccia OpenAPI 3 contenente una descrizione del corpo della richiesta, di una risposta o di un parametro superiore ai 255 caratteri si otteneva un errore inatteso sulla console;
la verifica dei certificati, su erogazioni/fruizioni ModI, andava in errore se veniva impostata una OCSP Policy.
Per la console di monitoraggio sono stati risolti i seguenti bug:
Sono stati apportati i seguenti miglioramenti:
viene adesso supportato una nuova modalità di fruizione ModI in cui il keystore utilizzato per la firma viene associato direttamente alla fruizione, in alternativa alla modalità già esistente in cui il keystore viene associato all'applicativo mittente;
aggiunta la possibilità di definire una token policy di negoziazione in cui i dati relativi al keystore, al KID e al clientId possono essere configurati nelle fruizioni con connettore che utilizza token policy con tali caratteristiche;
rivista la label 'Contemporaneità Token Authorization e Agid-JWT-Signature' in 'Coesistenza Token Authorization e Agid-JWT-Signature';
aggiunta la possibilità di registrare nelle fruizioni proprietà relative ad uno specifico applicativo mittente. La funzionalità è utilizzabile per configurare in una fruizione purposeId differenti per ogni applicativo mittente. Analogamente è ora possibile registrare proprietà diverse per ogni applicativo rispetto all'api invocata.
In una token policy di negoziazione è adesso possibile personalizzare i seguenti parametri della chiamata verso l'authorization server:
Inoltre anche nelle modalità di negoziazione standard già esistenti è stata aggiunta la possibilità di aggiungere header http personalizzati nella richiesta.
Infine è stato migliorato il tooltip visualizzato sul connettore di una erogazione in modo da visualizzare l'eventuale token policy associata.
La traccia prodotta da GovWay è stata arricchita:
La diagnostica è stata arricchita al fine di individuare:
Le informazioni sui messaggi di richiesta e di risposta visualizzate nel dettaglio di una transazione, tramite la console 'govwayMonitor', sono state riorganizzate per una migliore comprensione.
La latenza totale di una transazione viene adesso calcolata in base al momento in cui la spedizione dei messaggi in uscita verso il client sia stata completata.
Il termine 'latenza servizio' è stato rinominato in 'tempo di risposta servizio' in tutti i report statistici.
Sono stati apportati i seguenti miglioramenti alla console di gestione:
è adesso possibile effettuare ricerche di erogazioni e fruizioni rispetto allo stato della configurazione relativa alle seguenti funzionalità:
per i soggetti e per gli applicativi è stata aggiunta la possibilità di effettuare ricerche rispetto all'Issuer del certificato associato;
aggiunta la possibilità di registrare le classi dei plugin che implementano funzionalità personalizzabili relative al parsing delle risposte in una Token Policy di validazione o negoziazione e in una Attribute Authority.
Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
CVE-2022-45688: aggiornata libreria 'org.json:json' alla versione 20230227;
CVE-2023-24998: aggiornata libreria 'commons-fileupload' alla versione 1.5 .
Sono stati risolti i seguenti bug:
l'autorizzazione puntuale in una erogazione con profilo di interoperabilità 'ModI' non veniva effettuata se la lista degli applicativi autorizzati veniva lasciata vuota;
le regole di autorizzazione definite nell'autorizzazione dei contenuti o nell'autorizzazione per token claims non venivano controllate nell'ordine in cui erano state configurate;
la validazione di un token che presentava date (exp,iat,nbf) serializzate in un formato numerico esponenziale falliva generando un errore simile al seguente: 'Token non valido: For input string: "1.67"'
Per la console di gestione sono stati risolti i seguenti bug:
il controllo dei certificati di una token policy di negoziazione andava in errore quando la modalità scelta era 'Definito nell'applicativo ModI';
non era più possibile creare una token policy in caso di servizi OCSP disabilitati (file ocsp.properties non presente o nessuna policy definita al suo interno);
sono stati corretti i seguenti problemi relativi alla configurazione dell'autorizzazione per contenuti:
se nelle regole erano presenti commenti (#) potevano presentarsi segnalazioni errate dovuti a 'commenti duplicati' quando la linea inserita era la stessa in due o più righe;
in alcuni casi l'ordine di inserimento delle regole non veniva preservato in fase di salvataggio;
non venivano gestite correttamente più entry con la stessa chiave (la stessa problematica è stata risolta anche nella configurazione dell'autorizzazione per token claims).
Per la console di monitoraggio sono stati risolti i seguenti bug:
È stato introdotto il supporto al protocollo Online Certificate Status Protocol (OCSP), descritto nel RFC 2560, che consente di verificare la validità di un certificato senza ricorrere alle liste di revoca dei certificati (CRL).
GovWay consente di definire differenti molteplici policy OCSP, ad ognuna delle quali è possibile attribuire una modalità di validazione del certificato differente rispetto a vari parametri: dove reperire la url del servizio OCSP a cui richiedere la validità del certificato e il certificato dell’Issuer che lo ha emesso, come comportarsi se un servizio non è disponibile, eventuale validazione CRL alternativa etc.
Una policy OCSP è utilizzabile nelle seguenti funzionalità per attuare una validazione OCSP dei certificati presenti:
Profilo di Interoperabilità ModI: certificato utilizzato all'interno dei token di sicurezza 'ID_AUTH' e 'INTEGRITY';
Connettore HTTPS: certificato server;
WSSecurity e JOSE: certificato utilizzato per firmare il messaggio;
Token OAuth: certificato utilizzato per firmare il token;
Autenticazione HTTPS: certificato client;
Frontend HTTPS: certificati X.509 inoltrati a GovWay su header http dai frontend dove viene attuata la terminazione tls (Apache httpd, IIS, etc).
È adesso possibile caricare un certificato, da associare ad un applicativo o ad un soggetto, anche nei seguenti formati:
pkcs7 (p7b);
certificate chain.
Per ogni certificato è adesso possibile accedere anche alle seguenti informazioni:
ottenere i 'subject alternative names' presenti nel certificato;
accedere all'oggetto 'extensions' generico che raccoglie tutte le estensioni presenti nel certificato.
Nello script SQL generato per SQLServer è stata aggiunta una nota iniziale che indica il charset 'UTF-8' e la collection 'case sensitive' da utilizzare.
La lista completa dei bug risolti è disponibile in https://govway.readthedocs.io/it/latest/releaseNotes/3.3.10/bug.html
Sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
CVE-2022-46364: aggiornate librerie 'org.apache.cxf:cxf-*' alla versione 3.5.5 (e dipendenza org.ow2.asm:asm alla versione 9.4);
CVE-2022-41915: aggiornate librerie 'io.netty:netty-*' alla versione 4.1.86.Final.
Sono stati risolti i seguenti bug:
le operazioni riguardanti richieste definite tramite WSDL con stile rpc, non venivano riconosciute dal processo di lettura delle informazioni SOAP in streaming;
aggiunta proprietà 'validation.rpc.rootElementUnqualified.accept', configurabile nell'erogazione o nella fruizione, che consente di indicare se devono essere accettate o meno richieste RPC il cui root-element non appartiene ad alcun namespace in modo da poter disattivare il comportamento di default del prodotto che consente di accettare le richieste al fine di essere compatibile con framework soap datati;
un utilizzo di configurazioni che prevedono keystore PKCS12 o CRL in formato PEM su GovWay dispiegato nell'application server JBoss EAP 7.3 (aggiornato all'ultimo patch level) provocava il seguente errore: "java.lang.NoClassDefFoundError: org/bouncycastle/util/encoders/Base64 at org.bouncycastle.jcajce.provider.asymmetric.x509.PEMUtil.readPEMObject()";
la risoluzione dinamica di una risorsa che riferiva un metodo con un parametro contenente un punto non funzionava;
risolto problema di caching delle richieste su API SOAP, in alcune condizioni limite di errore, dove avveniva una inviduazione errata dell'azione.
Per la console di gestione sono stati risolti i seguenti bug:
la selezione di un numero di Entries da visualizzare differente dal default (20) provocava uno stato di attesa infinito della console causato dall'errore: "Uncaught ReferenceError: selectedIndex is not defined";
la verifica CSRF falliva erroneamente dopo un controllo dei riferimenti di un oggetto in 2 scenari d'uso differenti:
entrando nel dettaglio un soggetto (o applicativo o ruolo o scope), controllando i riferimenti dell'oggetto e successivamneto provandolo a salvare;
nelle liste controllando i riferimenti di un oggetto e successivamente provandolo ad eliminare;
era erroneamente concesso modificare la token policy associata ad un applicativo anche se quest'ultimo risultava censito puntualmente nel controllo degli accessi di una erogazione o fruizione;
la modifica delle credenziali di un applicativo di dominio esterno, per il profilo di interoperabilità 'ModI', non funzionava nel caso di credenziali di tipo 'Authorization PDND' o 'Authorization OAuth' nei seguenti casi:
modifica dell valore dell'identificativo;
aggiunta o eliminazione di un certificato X.509 all'autorizzazione per gestire l'integrità.
Per ogni certificato è adesso possibile accedere anche alle seguenti informazioni:
verificare se una Certificate Policy è presente o meno sul certificato ed accedere alle informazioni interne della policy;
verificare i basic constraints (CA, pathLen);
ottenere le Authority Information Access presenti nel certificato:
ottenere i CRL Distribution Points presenti nel certificato.
Sono stati risolti i seguenti bug:
con interfacce OpenAPI complesse di grandi dimensioni la validazione dei contenuti utilizzando la libreria "swagger-request-validator" impiegava diversi secondi ad inizializzare lo schema, anche per richieste successive alla prima dove le informazioni vengono salvate in cache;
la negoziazione di un token in modalità 'SignedJWT' utilizzando un keystore di tipo 'JWK Set' falliva con il seguente errore: "Errore avvenuto durante la consegna HTTP: (Errore di Connessione) JWT Signature keystore password undefined";
sono state risolte le seguenti vulnerabilità relative ai jar di terza parte:
Per la console di gestione sono stati risolti i seguenti bug:
utilizzando il database SQLServer l'accesso alla pagina di configurazione di una erogazione o fruizione produceva il seguente errore SQL: "ERROR ... org.openspcoop2.core.mapping.DBMappingUtils._mappingErogazionePortaApplicativaList: Ambiguous column name 'descrizione'";
la selezione della modalità 'interfaccia avanzata', tramite la voce presente nel menù in alto a destra, presentava le seguenti problematiche:
la modalità selezionata veniva erroneamente visualizzata anche accedendo al profilo dell'utenza, invece dei criteri configurati in maniera persistente per quell'utente;
anche se veniva selezionata la modalità 'interfaccia avanzata', la selezione di connettori differenti da http (jms, file, ...) non era disponibile se il profilo persistente associato all'utente era definito come 'interfaccia standard';
la modifica del keystore di un applicativo ModI, nella sezione 'Sicurezza Messaggio', provocava un errore e nel file di log era presente la segnalazione: "Parametro [confSSLCredWizStep] Duplicato.";
effettuando un export contenente la configurazione di un soggetto diverso dal soggetto di default dichiarato nell'installer, la successiva importazione dell'archivio in un'installazione in cui tale soggetto fosse stato definito come soggetto di default provocava una inconsistenza delle configurazioni, segnalata dalla console al momento del login.
Sono state aggiunte ulteriori modalità di estrazione dell'identificativo di correlazione applicativa:
Template: l'id di correlazione è il risultato dell'istanziazione del template fornito rispetto ai dati della richiesta;
Freemarker Template: l'id è ottenuto tramite il processamento di un Freemarker Template;
Velocity Template: l'id è ottenuto tramite il processamento di un Velocity Template.
Oltre alle informazioni standard previste dagli header di integrazione di GovWay, i client applicativi possono adesso fornire informazioni custom al gateway tramite un json il cui formato può essere arbitrariamente definito dal client.
Il json può essere inviato nell'header http 'GovWay-Integration' codificato in base64.
La presenza dell’header http non è obbligatoria ma se presente le informazioni contenute vengono rese disponibili per l'uso nelle varie funzionalità del gateway, come ad esempio la correlazione applicativa o l'utilizzo di claim custom nella generazione di token di sicurezza ModI, o nella generazione di asserzioni JWT per la negoziazione di token OAuth.
Per quanto concerne i claim aggiuntivi che possono essere aggiunti all'interno del payload dei JWT generati da GovWay è adesso possibile:
aggiungere il claim solamente se la risoluzione dinamica del valore viene effettuata con successo utilizzando la forma opzionale "?{..}";
definire tipi primitivi json (boolean,int,long,float,double) effettuando un cast nella forma "cast(<valore> as <tipoPrimitivo>)";
convertire una lista json di tipi primitivi in lista di stringhe effettuando un cast nella forma "cast(<valore> as string array)".
È stata introdotta una politica di generazione automatica degli header HTTP indicati di seguito, se non ritornati dal backend che implementa l'API, con lo scopo di evitare alcune vulnerabilità a cui possono essere soggette le implementazioni delle API:
X-Content-Type-Options: nosniff
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0
Vary: *
NOTE: Il caching viene disabilitato per evitare che delle risposte vengano inopportunamente messe in cache, come indicato nelle Linee Guida - raccomandazioni tecniche per REST 'RAC_REST_NAME_010'. Il mancato rispetto di questa raccomandazione può portare all’esposizione accidentale di dati personali.
Per la console di gestione sono stati risolti i seguenti bug:
Sono stati risolti i seguenti bug:
nel profilo di interoperabilità 'SPCoop' è stata eliminata la dichiarazione del namespace con prefisso 'SOAP_ENV' che veniva inserito nell'header eGov generato senza poi essere effettivamente utilizzato;
nelle informazioni salvate durante la negoziazione di un token non venivano memorizzati gli eventuali parametri indicati nella form: audience, scope, client_id, resource (PDND).
Per la console di gestione sono stati risolti i seguenti bug:
perfezionata la gestione delle vulnerabilità di tipo CSRF;
perfezionata la gestione dell'header http "Content Security Policy (CSP)";
la segnalazione 'Visualizza Riferimenti' di un applicativo non visualizzava applicativi con ruoli compatibili con le erogazioni associate;
l'associazione di credenziali di tipo basic/ssl/principal ai soggetti e agli applicativi viene adesso effettuata controllando l'univocità della credenziale su entrambi;
nella sezione 'sicurezza messaggio' di un applicativo con profilo di interoperabilità ModI, la configurazione relativa ai dati di accesso al keystore risultava eliminabile da console, ma l'operazione non comportava una effettiva pulizia nella base dati dove i dati rimanevano, anche se non più visualizzabili.
Per la console di monitoraggio sono stati risolti i seguenti bug:
Sono state aggiornate alle versioni più recenti tutte le librerie terza parte utilizzate al fine di risolvere tutte le vulnerabilità note.
Sono stati risolti i seguenti bug:
una richiesta POST senza contenuto e senza ContentType veniva erroneamente riconosciuta come non valida dal filtro CORS e di conseguenza non veniva generato l'header http 'Access-Control-Allow-Origin' nella risposta;
corretto errore di parsing che si presentava con alcune SOAPEnvelope:
"Invalid content (</SOAP-ENV:Envelope/>): The markup in the document preceding the root element must be well-formed.".
Sono stati introdotti miglioramenti prestazionali minimizzando gli accessi concorrenti alle varie cache di configurazione tramite l'ausilio di una cache di secondo livello che contiene tutti i dati principali raccolti durante la gestione della prima richiesta.
Per la console di monitoraggio sono stati risolti i seguenti bug:
utilizzando il database SQLServer la ricerca base nello storico delle transazioni produceva il seguente errore SQL:
"ERROR <20-10-2022 14:03:03.969> org.openspcoop2.core.commons.search.dao.jdbc.JDBCAccordoServizioParteSpecificaServiceSearch.findAll(348): Ambiguous column name 'tipo_soggetto'."
era erroneamente possibile cancellare testo nel contenuto di un messaggio visualizzato nel dettaglio di una transazione;
sono stati corrette le seguenti anomalie relative alla funzionalità di export CSV delle configurazioni:
l'export produceva risultati non deterministici e/o incompleti;
l'username associato ad una erogazione tramite servizio IntegrationManager/MessageBox non veniva riportato nel report.