Fruizione INTEGRITY_REST_02 (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 INTEGRITY_REST_02 - Integrità del payload delle request REST in PDND.

Nella figura “Fig. 210” viene raffigurato lo scenario di fruizione in cui il trust avviene tramite la PDND e viene prodotto il token “Agid-JWT-Signature” previsto dal pattern “INTEGRITY_REST_02”.

Di seguito vengono forniti i dettagli di configurazione aggiuntivi o differenti, rispetto ai passi descritti nella sezione “Fruizione ID_AUTH_REST_01 (PDND)”.

API

La registrazione della API deve essere effettuata agendo nella sezione «ModI - Sicurezza Messaggio», come indicato in Fig. 211:

• selezionare il “Pattern” «INTEGRITY_REST_02 con ID_AUTH_REST_01»;

• selezionare una “Generazione Token” di tipo “Authorization PDND” per far si che il Token “ID_AUTH” sia negoziato con la PDND.

Le voci “Header HTTP del Token” e “Applicabilità” consentono di personalizzare l’header HTTP utilizzato e di indicare se il pattern di sicurezza verrà attuato sia sulla richiesta che sulla risposta. Maggiori informazioni vengono fornite rispettivamente nelle sezioni “Header HTTP del token JWT” e “Attivazione della sicurezza messaggio su richiesta/risposta”.

Fruizione

Rispetto a quanto indicato nella sezione Fruizione ID_AUTH_REST_01 (PDND) l’interfaccia per la creazione della fruizione, basata su una API con pattern «INTEGRITY_REST_02 con ID_AUTH_REST_01», presenta le sezioni «ModI - Richiesta» e «ModI - Risposta» (compatibilmente con i criteri di applicabilità impostati nell’API):

• ModI - Richiesta (Fig. 212): la maschera relativa alla richiesta prevede la configurazione del meccanismo di firma digitale del messaggio, ad opera dell’applicativo mittente, e la produzione del relativo token di sicurezza:

  • Algoritmo: l’algoritmo che si vuole utilizzare per la firma digitale del messaggio;

  • Codifica Digest: consente di selezionare l’algoritmo utilizzato per produrre il digest;

  • HTTP Headers da firmare: indicazione degli eventuali Header HTTP da firmare;

  • KeyStore: lo scenario descritto in questa sezione è relativo alla configurazione proposta di default con la voce “Definito nell’applicativo”, mentre scenari differenti sono attuabili utilizzando le configurazioni descritte in Keystore di firma definito nella fruizione e Keystore di firma definito nella token policy;

  • Time to Live: tempo di validità del token prodotto (in secondi);

  • Audience: identificativo dell’applicativo destinatario da indicare come audience nel token di sicurezza; se non viene indicato alcun valore verrà utilizzato la url del connettore. Il valore fornito può contenere parti dinamiche risolte a runtime dal Gateway (per maggiori dettagli Valori dinamici).

  • Claims: consente di personalizzare i claims presenti all’interno del token prodotto. Per maggiori dettagli si rimanda alla sezione “Payload Claims del token JWT”.

  

• ModI - Risposta: la maschera relativa alla risposta è presente solamente se è stato selezionato un criterio di applicabilità nell’API che prevede la ricezione di un token di sicurezza messaggio anche nella risposta. La sezione consente di configurare il meccanismo di validazione del token ricevuto da parte dell’applicativo destinatario:

  • TrustStore Certificati: il pattern “INTEGRITY_REST_02”, prevede che all’interno del token sia presente un identificativo della chiave pubblica (kid) associata alla chiave privata utilizzata dal destinatario per firmare il token di risposta. L’identificativo kid è stato generato dalla PDND al momento della registrazione del materiale crittografico (chiave pubblica) da parte dell’applicativo destinatario ed è recuperabile dal mittente tramite le API messe a disposizione dalla PDND stessa. Per effettuare la validazione deve essere definito un truststore tramite una delle seguenti modalità alternative:

    • “Default”: può essere utilizzato il truststore di default descritto nella sezione “Trust tra fruitore ed erogatore tramite certificati X509”; in questo caso nel truststore deve essere presente un certificato registrato con un alias che corrisponde al “kid” veicolato nel token INTEGRITY.

    • “Ridefinito” con keystore di tipo “JWK Set” o “JKS”: consente di attuare una configurazione statica dove indicare il path su filesystem di un archivio json contenenti chiavi JWK o di un truststore contenenti certificati x509. In entrambi i casi l’archivio indicato deve contenere al suo interno una chiave pubblica o un certificato registrato con un alias che corrisponde al “kid” veicolato nel token INTEGRITY. (Fig. 213).

      

    • “Ridefinito” con keystore di tipo “PDND”: consente di attuare una configurazione dinamica in cui GovWay effettuerà lo scaricamento della chiave pubblica dalla PDND attraverso le API PDND se l’identificativo kid della chiave non è già presente nella cache locale (Fig. 214).

      

      Nella figura “Fig. 215” viene raffigurato lo scenario di fruizione durante la fase di validazione del token di risposta tramite un truststore dinamico in cui GovWay utilizza le API PDND per ottenere la chiave pubblica necessaria a validare il token di risposta.

      

  • Time to Live: consente di ridefinire l’intervallo temporale, in secondi, per il quale i token creati precedentemente all’intervallo indicato verranno rifiutati.

  • Verifica Audience: Se l’opzione è abilitata, viene effettuata la verifica che il campo Audience, presente nel token di sicurezza della risposta, corrisponda al valore presente nel campo successivo, se indicato, o altrimenti a quello configurato nell’applicativo mittente nella voce “Identificativo Client”.