Nel caso in cui il token sia di tipo JWT (quindi JWE o JWS), questa
opzione attiva la validazione basata su tale standard (Fig. 421).
Fig. 421 Dati di configurazione della validazione JWT
I dati da inserire sono:
Formato Token: indica il formato atteso del payload contenuto nel token JWT. Maggiori dettagli sul mapping vengono forniti in “Formati dei token”. I valori possibili sono:
Personalizzato: consente di definire un mapping puntuale tra il nome di un claim e l’informazione che GovWay cerca di estrarre dal token (Fig. 426);
Plugin: consente di selezionare un plugin che implementa una logica di parsing personalizzata (deve implementare l’interfaccia “org.openspcoop2.pdd.core.token.parser.ITokenParser”). Per dettagli si rimanda alla sezione Plugins.
Header: presente solo in caso di token di tipo JWS, consente di abilitare una validazione dei valori dei claim “typ”, “cty” o “alg” presenti nell’header.
Fig. 422 Dati di configurazione della validazione di un header JWS
TrustStore: I parametri di configurazione del truststore da utilizzare per il servizio di validazione. Nella configurazione proposta per default il certificato utilizzato per validare il token sarà quello presente all’interno del truststore, corrispondente all’identificativo indicato nel campo “Alias Certificato”. In alternativa il certificato è ottenibile tramite le informazioni presenti nel token jwt (x5c, x5t, x5u) attraverso la modalità indicata nel campo “Riferimento X.509”. Un certificato ottenuto tramite le informazioni presenti nel token jwt viene sempre validato rispetto al truststore e possono essere abilitati ulteriori criteri di verifica tramite CRL o Policy OCSP (vedi sezione Online Certificate Status Protocol (OCSP)).
Opzioni Avanzate
È possibile personalizzare il comportamento dell’engine di validazione dei token JWT rendendo obbligatoria la presenza dei claim “iat”, “exp” e “nbf”.
Nella configurazione predefinita, i claim “iat” e “exp” sono richiesti esclusivamente per le erogazioni che adottano il profilo di interoperabilità “ModI”. Il claim nbf, invece, è richiesto solo per le erogazioni “ModI” veicolate tramite la piattaforma PDND. Per estendere questa obbligatorietà ad altri contesti, è necessario configurare esplicitamente le seguenti proprietà, da applicare a livello di erogazione o fruizione, come descritto nella sezione :ref:configProprieta. Le proprietà supportano i valori booleani “true” o “false”:
tokenValidation.iat.required
tokenValidation.exp.required
tokenValidation.nbf.required
Questa configurazione consente di rafforzare i controlli di validità temporale dei token, migliorando la sicurezza degli scambi basati su JWT.
In alternativa è possibile agire a livello di configurazione generale editando il file <directory-lavoro>/govway_local.properties:
In alternativa è possibile agire a livello di configurazione generale personalizzando il comportamento oltre che per erogazioni e fruizioni anche per profilo di interoperabiltà. Di seguito un esempio per il profilo di interoperabiltà “ModI”:
# configurazione globale per profilo modipaorg.openspcoop2.pdd.gestioneToken.iat.erogazioni.modipa.required=trueorg.openspcoop2.pdd.gestioneToken.iat.fruizioni.modipa.required=trueorg.openspcoop2.pdd.gestioneToken.exp.erogazioni.modipa.required=trueorg.openspcoop2.pdd.gestioneToken.exp.fruizioni.modipa.required=trueorg.openspcoop2.pdd.gestioneToken.nbf.erogazioni.modipa.required=trueorg.openspcoop2.pdd.gestioneToken.nbf.fruizioni.modipa.required=true
