Fruizione (PDND)¶
Le richieste che provengono dagli applicativi interni del dominio e sono dirette verso altre amministrazioni verranno arricchite del token di sicurezza “ModI” previsto dall’operazione invocata, come indicato precedentemente nella sezione ID_AUTH tramite la Piattaforma Digitale Nazionale Dati (PDND).
Per la configurazione delle fruizioni con un pattern di sicurezza via PDND è necessario registrare una Token Policy di Negoziazione del tipo descritto nella sezione “Signed JWT (PDND)”.
Una volta effettuata la registrazione della Token Policy, per utilizzarla in una fruizione è sufficiente associarla al connettore della fruizione come descritto nella sezione Autenticazione Token.
Di seguito vengono riportati tutte le informazioni da registrare nella policy:
Tipo: SignedJWT;
PDND: flag attivato;
URL: endpoint esposto dalla PDND su cui è possibile richiedere lo stacco del voucher;
Fig. 159 Token Policy di Negoziazione PDND (Endpoint)¶
JWT Keystore: parametri di accesso al keystore contenente la chiave privata corrispondente al certificato X509 caricato sulla PDND durante la registrazione dell’applicativo client. I parametri variano in funzione del tipo di keystore selezionato:
“JKS”, “PKCS12”, “JWK Set”: deve essere definito il path su filesystem dove risiede il keystore, la password per l’accesso al keystore, l’alias con cui è riferita la chiave privata e la password;
Fig. 160 Token Policy di Negoziazione PDND (Keystore PKCS12)¶
“Definito nell’applicativo ModI”: il keystore utilizzato per firmare l’asserzione JWT inviata alla PDND sarà quello definito nell’applicativo ModI richiedente come descritto nella sezione “Fruizione”;
Fig. 161 Token Policy di Negoziazione PDND (Keystore definito nell’applicativo ModI)¶
“Definito nella fruizione ModI”: il keystore utilizzato per firmare l’asserzione JWT inviata alla PDND sarà quello definito nella fruizione ModI come descritto nella sezione “Parametri PDND (Keystore, KID e clientId) definiti nella fruizione”;
Fig. 162 Token Policy di Negoziazione PDND (Keystore definito nella fruizione ModI)¶
Tipi PKCS11: gli altri tipi disponibili sono quelli corrispondenti ai tipi di keystore PKCS11 registrati (“Device PKCS11”).
JWT Signature: algoritmo di firma
Fig. 163 Token Policy di Negoziazione PDND (Algoritmo di Firma)¶
JWT Header:
Type (typ): lasciare il valore “JWT”;
Key Id (kid): deve essere indicato l’identificativo univoco (KID) associato al certificato caricato sulla PDND e ottenuto al termine della registrazione dell’applicativo client. Può essere fornito tramite una delle seguenti modalità:
“Personalizzato”: selezionando la modalità “Personalizzato” è possibile indicarlo puntualmente. Il valore può essere definito come costante o contenere parti dinamiche risolte a runtime dal Gateway (“Valori dinamici”);
Fig. 164 Token Policy di Negoziazione PDND (KID personalizzato)¶
“Definito nell’applicativo ModI”: nel caso in cui è stato indicato un keystore definito nell’applicativo ModI, è possibile selezionare una modalità analoga anche per il KID (Fig. 165).
Fig. 165 Token Policy di Negoziazione PDND (KID definito nell’applicativo ModI)¶
Questa modalità richiede che oltre al keystore, nell’applicativo ModI richiedente descritto nella sezione “Fruizione”, venga abilitata anche la sezione “Authorization OAuth” e venga indicato il KID nel campo “Key Id del Certificato” (Fig. 166).
Fig. 166 Dati Autorizzazione OAuth relativi ad un applicativo interno¶
“Definito nella fruizione ModI”: nel caso in cui è stato indicato un keystore definito nella fruizione ModI, è possibile selezionare una modalità analoga anche per il KID (Fig. 167).
Fig. 167 Token Policy di Negoziazione PDND (KID definito nella fruizione ModI)¶
Questa modalità richiede che oltre al keystore, nella fruizione ModI venga abilitata anche la sezione “Authorization PDND” e venga indicato il KID nel campo “Key Id del Certificato” come descritto nella sezione “Parametri PDND (Keystore, KID e clientId) definiti nella fruizione”.
JWT Payload:
l’identificativo univoco dell’applicativo client (“client_id” o “sub”) ottenuto al termine della registrazione dell’applicativo sulla PDND deve essere indicato nei seguenti campi:
Client ID
Issuer
Subject
Fig. 168 Token Policy di Negoziazione PDND (ClientId)¶
In alternativa nel caso in cui sia stato indicato un keystore definito nell’applicativo ModI, è possibile selezionare una modalità analoga anche per la tripla clientId/issuer/subject (Fig. 169).
Fig. 169 Token Policy di Negoziazione PDND (ClientId definito nell’applicativo ModI)¶
Questa modalità richiede che oltre al keystore, nell’applicativo ModI richiedente descritto nella sezione “Fruizione”, venga abilitata anche la sezione “Authorization OAuth” e venga indicato il clientId nel campo “Identificativo” (Fig. 170).
Fig. 170 Dati Autorizzazione OAuth relativi ad un applicativo interno¶
In alternativa nel caso in cui sia stato indicato un keystore definito nella fruizione ModI, è possibile selezionare una modalità analoga anche per la tripla clientId/issuer/subject (Fig. 171).
Fig. 171 Token Policy di Negoziazione PDND (ClientId definito nella fruizione ModI)¶
Questa modalità richiede che oltre al keystore, nella fruizione ModI venga abilitata anche la sezione “Authorization PDND” e venga indicato il clientId nel campo “Identificativo” come descritto nella sezione “Parametri PDND (Keystore, KID e clientId) definiti nella fruizione”.
Gli altri campi presenti nella sezione “JWT Payload” rappresentano (Fig. 172):
Audience: indica il servizio di stacco del voucher della PDND. Il valore, fornito dalla PDND, è indipendente dal servizio per cui si vuole richiedere un voucher e varia solamente in funzione dell’ambiente di validazione o produzione della PDND stessa;
Identifier: consente di configurare la modalità di valorizzazione del claim “jti” presente all’interno del token di richiesta inviato alla PDND. Si suggerisce di valorizzare il campo con la keyword “${transaction:id}” al fine di utilizzare l’identificativo di transazione della richiesta;
Time to Live (secondi): consente di indicare la durate del token di richiesta inviato alla PDND (es. 100 sec);
Purpose ID: identificativo univoco della finalità per cui si intende fruire di un servizio. Il valore può essere fornito staticamente o può contenere una keyword risolta a runtime in modo da valorizzare il claim purposeId con un valore prelevato dai dati della richiesta. Ad esempio se il censimento dei purposeId viene mantenuti a livello applicativo può essere indicato un header HTTP con cui il richiedente può fornire a GovWay il valore da utilizzare (es. ${header:NOME_HEADER_HTTP}). Se invece il purposeId viene registrato come proprietà di una fruizione può essere valorizzato con il valore “${config:NOME_PROPRIETA}”. Si rimanda alla sezione “Valori dinamici” per le varie modalità dinamiche utilizzabili.
Informazioni Sessione: consente di valorizzare il claim “sessionInfo” previsto dalla PDND. La valorizzazione può essere statica o formata da parti dinamiche risolte a runtime dal Gateway (per maggiori dettagli Valori dinamici).
Fig. 172 Token Policy di Negoziazione PDND (JWT Payload)¶
Dati Richiesta:
Resource: indicare l’audience/url del servizio per cui si vuole richiedere un voucher;
Client ID: indicare il medesimo valore inserito nel campo “Client ID” della sezione “JWT Payload”;
Fig. 173 Token Policy di Negoziazione PDND (DatiRichiesta)¶
Per quanto concerne il campo “Client ID”, nel caso in cui sia stato indicato un keystore definito nell’applicativo ModI, è possibile selezionare una modalità analoga anche per il campo “Client ID” (Fig. 174).
Fig. 174 Token Policy di Negoziazione PDND (DatiRichiesta, ClientId definito nell’applicativo ModI)¶
Nel caso invece in cui sia stato indicato un keystore definito nella fruizione ModI, è possibile selezionare una modalità analoga anche per il campo “Client ID” (Fig. 175).
Fig. 175 Token Policy di Negoziazione PDND (DatiRichiesta, ClientId definito nella fruizione ModI)¶