Payload Claims del token JWT

Il pattern di sicurezza, su API di tipo REST, produrrà la generazione di un token JWT firmato inserito all’interno dell’header HTTP previsto dalle Linee Guida AGID di Interoperabilità. Nel payload del JWT vengono generati i claim di default previsti dal prodotto come quelli temporali (iat, nbf, exp), l’identificativo unico della richiesta (jti), e altri claims che consentono di individuare gli attori (sub, iss, client_id, aud).

Altri claims possono essere aggiunti al payload JWT definendoli nel campo “Claims” tra i criteri di configurazione “ModI” della richiesta, in una fruizione, o della risposta, in una erogazione. Vanno indicati per riga nella forma “nome=valore” come mostrato nella figura Fig. 251. Il valore può essere definito come costante o contenere parti dinamiche, definite tramite una sintassi proprietaria di GovWay, che verranno risolte a runtime dal Gateway (per maggiori dettagli Valori dinamici). Ulteriori modalità per aggiungere claim proprietari vengono descritti nella sezione Aggiunta di Claims nei Token.

../../../../_images/modipa_sicurezza_claims_custom.png

Fig. 251 Claims aggiuntivi inseriti nel Payload JWT

Nota

Non è consentito indicare i claims “iat, nbf, exp, jti”. In una richiesta non è inoltre consentito indicare ne il claim “aud” ne il claim “client_id” (quest’ultimo prevede un caso eccezionale con il valore ${notGenerate} descritto in seguito). In una risposta, invece, non è consentito indicare il claim “request_digest”.

Di seguito vengono forniti i valori di default inseriti da GovWay nel payload jwt per quanto concerne i claims che individuano gli attori, differenziando tra il token di richiesta generato da una fruizione e il token di risposta generato da una erogazione. Per ogni claim viene anche indicato come modificare il valore di default associato.

  • “aud”: indica a chi è riferito il security token

    • fruizione: il valore da inserire nel payload JWT può essere indicato tra i criteri di configurazione “ModI”, nella sezione richiesta. Se non viene fornito un valore verrà utilizzata la url del connettore.

    • erogazione: viene utilizzato il primo valore che ha un match in ordine con i seguenti criteri:

      • claim “aud” indicato nel campo “Claims” tra i criteri di configurazione “ModI” della risposta;

      • valore configurato nel campo “Identificativo Client” dell’applicativo mittente identificato;

      • valore presente nel claim “client_id” del payload JWT ricevuto nella richiesta;

      • valore presente nel claim “sub” del payload JWT ricevuto nella richiesta;

      • valore “anonymous”

    Nota

    Il claim “aud”, inserito nei token generati nella richiesta in una fruizione e nella risposta in una erogazione, viene generato come “single case-sensitive string”. È possibile generarlo come “array of case-sensitive strings” indicandolo tra array (es. [valoreAudience]) e in questo caso è possibile indicare anche molteplici valori (es. [valoreAudience1,valoreAudience2]).

  • “iss”: identificativo del soggetto che ha rilasciato (e firmato) il token; viene utilizzato il primo valore che ha un match in ordine con i seguenti criteri:

    • claim “iss” indicato nel campo “Claims” tra i criteri di configurazione “ModI” della richiesta, in una fruizione, o della risposta, in una erogazione;

    • identificativo del soggetto fruitore in una fruizione o l’identificativo del soggetto erogatore in una erogazione

  • “sub”: identificativo del mittente a cui è riferito il token; viene utilizzato il primo valore che ha un match in ordine con i seguenti criteri:

    • claim “sub” indicato nel campo “Claims” tra i criteri di configurazione “ModI” della richiesta, in una fruizione, o della risposta, in una erogazione;

    • in una fruzione l’identificativo varia a seconda della modalità di keystore:

      • nel caso di keystore di firma associato all’applicativo mittente viene utilizzato l’identificativo dell’applicativo;

      • nel caso di keystore definito nella fruizione viene utilizzato l’identificativo e la versione dell’API fruita;

    • in una erogazione viene utilizzato l’identificativo e la versione dell’API implementata.

  • “client_id”: identificativo dell’applicazione client che ha ottenuto il token; viene utilizzato il primo valore che ha un match in ordine con i seguenti criteri:

    • fruizione che richiede un keystore associato all’applicativo mittente:

      • valore configurato nel campo “Identificativo Client” dell’applicativo mittente identificato;

      • identificativo dell’applicativo mittente

    • fruizione che richiede un keystore associato alla fruizione:

      • identificativo e versione dell’API fruita

    • erogazione:

      • claim “client_id” indicato nel campo “Claims” tra i criteri di configurazione “ModI” della risposta;

      • identificativo e versione dell’API implementata

Nota

È possibile utilizzare la keyword “${notGenerate}” come valore dei claims “iss”, “sub” o “client_id”, indicati nel campo “Claims” tra i criteri di configurazione “ModI”, per non far generare il claim all’interno del jwt payload.