AUDIT_REST_01 richiedente in Agid-JWT-TrackingEvidence claims non obbligatori da RFC 7519 e 7515: aud,jti,iat,exp

[nicolabeghin]

Descrizione del Bug Inviando token Agid-JWT-TrackingEvidence con profilo audit AUDIT_REST_01 attivato govway richiede obbligatoriamente i seguenti claim che non sono obbligatori da RFC 7519 e RFC 7515

• aud: audience
• jti: UUID4
• iat: issued
• exp: expiration

Riferimento codice: https://github.com/link-it/govway/blob/07ecc8cb5cdcc16ac77c54b25a4eb0db785759b7/protocolli/modipa/src/org/openspcoop2/protocol/modipa/validator/ModIValidazioneSintatticaRest.java#L953

Non chiaro se tali claim siano obbligatori o meno anche per PDND: issue https://github.com/italia/api-padigitale2026-misura1.3.1-uni-afam/issues/212

Come riprodurlo: Inviare token Agid-JWT-TrackingEvidence con profilo audit AUDIT_REST_01 attivato senza uno dei seguenti claim: aud,jti,iat,exp - ad esempio iat

Risultato atteso: Token accettato

Screenshots:

Ambiente:

• OS: Docker (govway-docker)
• Browser: [e.g. Chrome 75]
• GovWay: 3.3.14
• AS: Tomcat9
• DBMS: Postgres

Note aggiuntive: Effettuato un dummy check se fosse possibile effettuare un override tramite configurazione, ma non funziona

org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.nome=iat
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.label=Issued
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.required=false
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.stringType=true
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.info=iat
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.rule=${header:GovWay-Audit-User},${query:govway_audit_user}
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.rule.info=Header http 'GovWay-Audit-User',Parametro della url 'govway_audit_user'
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.forwardBackend=
org.openspcoop2.protocol.modipa.sicurezzaMessaggio.audit.pattern.optional.claims.iat.trace=false

[andreapoli]

Buongiorno @nicolabeghin.

I claim indicati sono definiti come obbligatori da Agid nelle "Linee Guida sull’interoperabilità tecnica delle Pubbliche Amministrazioni –Pattern di sicurezza" nel capitolo "6.1 [AUDIT_REST_01] Inoltro dati tracciati nel dominio del Fruitore REST"

Riporto alcuni frammenti della specifica:

[andreapoli]

override tramite configurazione, ma non funziona

Non è possibile effettuare l'override dei suddetti campi poichè ritenuti obbligatori da Agid.

[nicolabeghin]

Grazie @andreapoli credo tu sia la persona più competente in materia di tutta Italia! Linkato anche nel ticket di PDND https://github.com/italia/api-padigitale2026-misura1.3.1-uni-afam/issues/212 e chiudo.

[denismarini]

Buongiorno @nicolabeghin,

Un’osservazione riguardo al protocollo [AUDIT_REST_01]: l’inoltro dei dati tracciati nel dominio del Fruitore REST. Questo tipo di comunicazione viene utilizzata in casi molto specifici, quando la normativa impone all’erogatore di acquisire dati tracciati nel dominio del fruitore.

Pertanto, viene richiesta anche l’inclusione di informazioni aggiuntive nella pubblicazione dell’e-service da parte dell’erogatore.

[nicolabeghin]

Pertanto, viene richiesta anche l’inclusione di informazioni aggiuntive nella pubblicazione dell’e-service da parte dell’erogatore.

Sicuramente, ma claim custom aggiuntivi rappresentano un di più rispetto a quelli obbligatori richiesti dal token in oggetto motivo per il quale @andreapoli ha risposto (a mio parere) in maniera inappuntabile. Lato nostro non richiederemo claim aggiuntivi, neppure quelli aggiuntivi previsti da AUDIT_01 quindi documenteremo che sono richiesti solo quelli obbligatori da documentazione ufficiale.

[denismarini]

Il profilo di sicurezza da utilizzare nella 1.3.1 UNIAFAM è quello base per il protocollo REST, ossia [ID_AUTH_REST_01] Direct Trust con certificato X.509 REST e non sono richieste informazioni aggiuntive da parte del fruitore. Grazie alla sua segnalazione abbiamo aggiornato anche le line guida all'implementazione degli e-service sulla specifica 1.3.1 UNIAFAM

[nicolabeghin]

@andreapoli c'è una motivazione specifica per cui togliendo la parte di audit dalle API

le erogazioni collegate non funzionano più in quanto mancanti della sezione "Profilo interoperabilità" ModI?

PRIMA

DOPO

Per il momento aggirato non togliendo audit ma mettendolo Opzionale:

grazie

[andreapoli]

Buongiorno @nicolabeghin.

Utilizzando solo il pattern 'ID_AUTH_REST' con la Generazione Token 'PDND', tutte le informazioni necessarie per validare l'unico token atteso, il voucher della PDND, risiedono nella Token Policy. Per questo motivo, la sezione 'ModI' nell'erogazione non è più disponibile.

Pertanto, il comportamento che hai rilevato è quello previsto. Non ho però capito se, a seguito della modifica, stai riscontrando errori nelle chiamate e, in tal caso, quale errore viene riportato nei diagnostici della transazione.

[nicolabeghin]

Grazie @andreapoli l'errore è derivante dalla mancata validazione del claim aud il cui valore atteso è infatti popolato nella (disabilitata/nascosta) sezione "Profilo interoperabilità" (Modi)

Eccezione ERROR con codice [GOVWAY-814] - EccezioneValidazioneProtocollo: [Header 'Authorization'] Token contenente un claim 'aud' non verificabile; autorizzazione per token claim non definita

Non mi pare tale parametrizzazione sia presente nella Token Policy, ma credo di averla trovata nell'Erogazione stessa, sezione Controllo Accessi -> Autorizzazione -> ABILITATO poi Autorizzazione per Token Claims e poi da lì inserendo il valore atteso in una riga apposita - è un pò meno user-friendly di un campo apposito per l'audience prevista ma alla fine se fa quel che deve fare apposto!

grazie nicola

[andreapoli]

@nicolabeghin, hai seguito perfettamente quanto indicato nella sezione Erogazione ID_AUTH_REST_01 (PDND), soprattutto per quanto riguarda la 'Verifica Audience'.