link-it
Configurazione Fruizione e-service PDND
Buongiorno, sto configurando una fruizione su GovWay per l’e-service ANNCSU – Aggiornamento Coordinate Accessi su PDND (collaudo). Di seguito elenco i passaggi che ho eseguito e i problemi che ho riscontrato.
-
Accesso all'e-service senza GovWay: Per prima cosa ho seguito la guida presente sull'area riservata PDND Interoperabilità per accedere "manualmente" all'e-service, la quale prevedeva la generazione di una Client Assertion tramite uno script python, e la generazione dell'Access Token (voucher) effettuando una chiamata curl a "https://auth.uat.interop.pagopa.it/token.oauth2" esibendo la Client Assertion appena generata. Una volta generato l'Access Token, esibendolo in una chiamata curl all'endpoint dell'e-service /status, ricevo risposta {"status":"up"}. In particolare il comando è: curl --insecure --location --request GET "https://modipa-val.agenziaentrate.it/govway/rest/in/AgenziaEntrate-PDND/anncsu-aggiornamento-coordinate/v1/status" --header "Authorization: Bearer <ACCESS_TOKEN>" -H "Accept: application/json"
-
Configurazione GovWay Per automatizzare la creazione dell'Access Token ho provato a configurare l'istanza GovWay installata sul mio computer seguendo questi passaggi:
-
Registrazione soggetto Erogatore (specificando l'idEnte)
-
Registrazione soggetto Fruitore (specificando l'idEnte) Gli ID dei due enti sono stati recuperati dall'area riservata PDND Interoperabilità.
-
Registrazione dell'API facendo l'upload di un file specifica.yml: nella sezione "Sicurezza Canale" ho impostato "ID_AUTH_CHANNEL_01"; nella sezione "Sicurezza Messaggio" ho impostato "INTEGRITY_REST_02 con ID_AUTH_REST_02", con: Generazione Token -> Authorization PDND, Header HTTP del Token -> Agid-JWT-Signature+Authorization Bearer.
-
Creazione di una Token Policy di negoziazione. nella sezione "Token Endpoint": Tipo -> Signed JWT; flag PDND spuntato; URL -> https://auth.uat.interop.pagopa.it/token.oauth2 (recuperato dall'area riservata); JWT Keystore Tipo -> Definito nella fruizione ModI; JWT Signature Algorithm -> RS256; JWT Header kid -> definito nella fruizione ModI; JWT Header type -> JWT; JWT Payload Client ID -> personalizzato (recuperato dall'area riservata); JWT Payload Issuer e Subject -> uguali a Client ID; JWT Payload Audience -> https://auth.uat.interop.pagopa.it/token.oauth2; JWT Payload PurposeID -> personalizzato (recuperato dall'area riservata); Dati richiesta resource -> https://modipa-val.agenziaentrate.it/govway/rest/in/AgenziaEntrate-PDND/anncsu-aggiornamento-coordinate/v1 (dall'area riservata. Nota: sull'area riservata è indicato un URL differente da quello della specifica yml. Ho inserito quello dell'area riservata perchè effettuando la chiamata con curl, risponde con {"status":"up"}.). nella sezione "Token Forward" ho impostato la modalità "RFC 6750 - Bearer Token Usage (Authorization Request Header Field)"
-
Registrazione della Fruizione, specificando i soggetti creati in precedenza, l'API registrata in precedenza e la policy creata in precedenza. In particolare: nella sezione Controllo degli accessi -> Autenticato. nella sezione Connettore ho inserito il valore "https://modipa-val.agenziaentrate.it/govway/rest/in/AgenziaEntrate-PDND/anncsu-aggiornamento-coordinate/v1" nella sezione "ModI - Richiesta": Keystore -> definito nella fruizione; Modalità -> file system; tipo -> key pair (specificando il path delle chiavi pubblica e privata, che ho inserito nella directory D:\Govway\modipa)
- Accesso all'e-service Per effettuare le chiamate all'e-service, ho installato Postman. L'URL di invcazione che inserisco è "URL Invocazione" (recuperbaile dalla sezione Fruizioni di GovWay) + "/status", con metodo GET (http://localhost:8080/govway/rest/out/ComuneParma/AgenziaEntrate/AggiornamentoCoordinateAccessi/v3/status). La risposta che ottengo è la seguente: { "type": "https://govway.org/handling-errors/401/TokenAuthenticationRequired.html", "title": "TokenAuthenticationRequired", "status": 401, "detail": "A token is required", "govway_id": "062681db-a803-11f0-8566-d89ef33b9f66" } Se poi provo a generare "manualmente" l'Access Token, col metodo del punto 1, inserendolo nella sezione Header con key Authorization, effettuando la stessa chiamata la risposta che ottengo è la seguente: { "type" : "https://govway.org/handling-errors/503/APIUnavailable.html", "title" : "APIUnavailable", "status" : 503, "detail" : "The API Implementation is temporary unavailable", "govway_id" : "06268125-a803-11f0-8566-d89ef33b9f66" }
Ho provato ad eseguire un test di connettività come spiegato alla pagina https://govway.org/documentazione/console/handling-errors/503/APIUnavailable.html della documentazione, ma viene generato il seguente messaggio di errore: "Test di connettività fallito: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target".
La configurazione della fruizione ModI e della Token Policy PDND è corretta? I passaggi svolti sarebbero sufficienti al corretto funzionamento della chiamata o mancano ulteriori configurazioni o implementazioni? Configurato in questo modo, GovWay riesce a generare automaticamente la Client Assertion per ottenere l'Access Token? Se sì, quale potrebbe essere il motivo per cui non viene inserito il token nell'header della richiesta?
Se può risultare utile posso caricare il file di specifica API .yml.
Ringrazio anticipatamente per il supporto. Cordiali saluti.
Buongiorno @MatteoMalaguti8
Potresti riportare nell’issue la configurazione relativa al controllo degli accessi della fruizione che hai implementato? Dal tuo racconto sembra che tu abbia configurato in modo non corretto un’autenticazione basata su token, ipotizzo utilizzando come criterio di validazione la token policy PDND built-in.
Il controllo degli accessi ha lo scopo di definire i criteri di autenticazione e autorizzazione degli applicativi che invocano la fruizione, e non i pattern di sicurezza che vengono aggiunti alla richiesta da GovWay. Questi ultimi sono infatti gestiti sia nella maschera ModI, sia nella token policy di negoziazione associata al connettore.
Infine l’errore “unable to find valid certification path to requested target” è invece dovuto al fatto che il certificato server non risulta verificabile rispetto al truststore in uso, presumibilmente quello di Java.
L’errore “unable to find valid certification path to requested target” è stato risolto importando il certificato server nel truststore di Java. Per quanto riguarda la configurazione del controllo degli accessi:
- Autenticazione Token:
- stato -> abilitato
- policy -> PDND (built-in)
- validazione JWT -> abilitato
- spuntati i flag: issuer, clientId, subject
-
Autenticazione trasporto: stato -> https
-
Autorizzazione: stato -> disabilitato
-
Autorizzazione contenuti: stato -> disabilitato
Modificando il punto 3, compare il bollino rosso accanto alla fruizione, con messaggio: "Rilevato 'Controllo degli Accessi' con autorizzazione token/trasporto per richiedente, senza alcun fruitore registrato"
Buonasera @MatteoMalaguti8
Nello scenario che hai presentato, effettuando una fruizione non hai bisogno di abilitare l'autenticazione token nel controllo degli accessi.
La negoziazione del token con la PDND avverrà grazie all'associazione della Token Policy con il connettore.
Per maggiori dettagli ti suggerisco di esaminare gli scenari tipici di configurazione ad esempio per il Pattern “ID_AUTH” via PDND + “INTEGRITY_01”
Buongiorno Andrea, sono riuscito a risolvere il problema della negoziazione del token, che al momento avviene correttamente. Invocando l'e-service, ottengo però la seguente risposta: { "type": "https://govway.org/handling-errors/502/InvalidResponse.html", "title": "InvalidResponse", "status": 502, "detail": "Invalid response received from the API Implementation", "govway_id": "1c3e4d89-a9a8-11f0-966b-d89ef33b9f66" } La transazione dalla console di monitoraggio presenta il seguente errore: Validazione security token ModI 'INTEGRITY' della risposta fallita: [GOVWAY-1355] Signature verification failed: [COMPACT] Signature verification failure: Process 'kid' error: Certificato, corrispondente al kid 'oZm7LPy8ZX5xIqNXQTbn8e7f91xzR_PvYjTLJf2t0jo', non trovato nel TrustStore dei certificati
Il truststore utilizzato, come detto nei messaggi precedenti, è quello di default di Java. Nella maschera ModI-Risposta della configurazione della fruizione ho infatti lasciato il campo TrustStore Certificati su default. Non riesco a capire qual è il certificato mancante e come faccio a recuperarlo a partire dal kid oZm7LPy8ZX5xIqNXQTbn8e7f91xzR_PvYjTLJf2t0jo. Sarebbe una soluzione migliore importare il certificato mancante nel truststore di Java oppure ridefinire il truststore nella maschera ModI-Risposta, per esempio con un remoteStore di tipo PDND?
Grazie ancora del supporto, buona giornata.
Buongiorno @MatteoMalaguti8
Per comprenere quale truststore di validazione dei certificati viene utilizzato per default puoi consultare la seguente documentazione.
Buongiorno @andreapoli, ho lo stesso identico problema, con la stessa chiave e lo stesso e-service.
Il test eseguito sulle api, che forniscono risposte di mancata corrispondenza, funzionano correttamente (probabilmente non firma nessuna risposta). Il test su un dato esistente (verificato in precedenza) ci restituisce:
Validazione security token ModI 'INTEGRITY' della risposta fallita: [GOVWAY-1355] Signature verification failed: [COMPACT] Signature verification failure: Process 'kid' error: Retrieve remote key 'oZm7LPy8ZX5xIqNXQTbn8e7f91xzR_PvYjTLJf2t0jo' failed: Retrieve external resource 'https://api.interop.pagopa.it/1.0/oZm7LPy8ZX5xIqNXQTbn8e7f91xzR_PvYjTLJf2t0jo' failed: (http code: 403): {"message":"Authorization header requires 'Credential' parameter. Authorization header requires 'Signature' parameter. Authorization header requires 'SignedHeaders' parameter. Authorization header requires existence of either a 'X-Amz-Date' or a 'Date' header. (Hashed with SHA-256 and encoded with Base64) Authorization=5FjYp2fA5hjGqvy6zmqP4pU/6QOBoZBsU8z5izh2Qzg="}
Come vedi il kid riferito al certificato mancante è il medesimo indicato da @MatteoMalaguti8 .
Chiedo ad @andreapoli se ha indicazioni e a @MatteoMalaguti8 se è riuscito a trovare una soluzione.
Grazie per l'aiuto che riuscirete a darmi.
Buongiorno @dcaviglia, per risolvere il problema ho agito in questa maniera:
- creato un Client API Interoperabilità con relativo materiale crittografico sulla PDND
- utilizzato la fruizione built-in api-pdnd@PDNDv1 di GovWay per accedere all'API esposte dalla PDND (per farlo occorre configurare la fruizione stessa e la token policy built-in api-pdnd), in particolare alla risorsa GET /keys/{kid}
- invocato tale metodo specificando il kid oZm7LPy8ZX5xIqNXQTbn8e7f91xzR_PvYjTLJf2t0jo
- inserito la risposta ottenuta (oggeto JWK) nel TrustStore di risposta (impostato su JWK Set)
Spero di essere stato utile, buona giornata.
@MatteoMalaguti8 ti ringrazio molto !
Con la tua procedura sono andato effettivamente avanti, anche se ora testando il POST gestionecoordinate ottengo un errore di Risposta applicativa che non riesco ad interpretare.
magari è capitato anche a te
Grazie davide
Ho provato ad effettuare la richiesta POST gestionecoordinate in questo momento, e ottengo esattamente lo stesso errore; mentre fino a questa mattina funzionava correttamente. Non so a cosa possa essere dovuto
Aggiornamento: ora sembra ripartito... probabilmente si trattava di qualche malfunzionamento dei server dell'AE
Alla fine sono riuscito a farlo funzionare.
- in ModI risposta della fuizione nella verifica Audience, ho settato il client_Id (ho verificato nella Agid-JWT-Signature mi passava quella)
Ho però dovuto settare in ModI risposta come Trust dei certificati il JWK set con path fisso: eseguendo la procedura che mi hai indicato per recuerare la chiave con il kid.
Chiedo a @andreapoli : se setto PDND come TrustStore dei certificato per il ModI risposta, come mai non funziona e mi restituisce sempre che non trova la chiave corrispondende con il kid ? E' una caratteristica spedifica di questa Erogazione (ANNCSU aggiornamento coordinate) oppure c'è una ragione tecnica che non ho capito?
Grazie
Buonasera @dcaviglia
Per usare il truststore 'PDND' deve essere effettuata la configurazione indicazione nella documentazione API PDND.
GovWay utilizzera la fruizione built-in per recuperare la chiave pubblica necessaria a validare il token.
Ciao @andreapoli ero convinto di aver configurato correttamente, seguendo in modo attento la documentazione.
Forse è un problema nel modipa_loca.properties. Lo allego così se hai tempo puoi verificarlo.
Grazie
Buongiorno @dcaviglia
Dal log che mi hai indicato vedo che hai configurato
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.certificati.remoteStore.pdnd.baseUrl = https://api.uat.interop.pagopa.it/1.0/keys
In questa proprietà deve essere configurato l’URL di invocazione della fruizione built-in, come descritto nella documentazione API PDND, e non l’URL della PDND stessa. In caso contrario, viene omessa l’aggiunta automatica del token autorizzativo richiesto dalle API di PDND.
Grazie @andreapoli , abbiamo risolto con le tue preziose indicazioni
Abbiamo verificato che va indicato nel file di configurazione direttamente l'endpoint delle API nel paramentro baseUrl
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.certificati.remoteStore.pdnd.baseUrl = https://api.iolweb.it/fruizioni/govway/rest/out/Ente/PDND/api-pdnd/v1/keys
Davide