Chiarimenti verifica di un voucher da parte di un erogatore

[fdl90]

Salve,
in questa sezione https://docs.pagopa.it/interoperabilita-1/manuale-operativo/utilizzare-i-voucher, è specificato che, per la verifica di un voucher, bisogna considerare i seguenti claims: iss, exp e aud.
Inoltre, è aggiunto che DIVERSI e-service possano avere la STESSA audience.
In tal caso, limitandosi solo alla validazione dei parametri di cui sopra, come fa l'erogatore ad essere certo di autorizzare effettivamente un fruitore valido?
Non bisognerebbe validare anche il client id o il purpose id?

[FedericaSicchiero]

Buongiorno, ci scusiamo per il ritardo nella risposta.
Il poter staccare un voucher presuppone che prima siano stati fatti dei passaggi amministrativi (come l'accettare la finalità) che garantiscono la validità della richiesta del fruitore verso l'erogatore. Per questo nella documentazione si dice di considerare quei campi invece di altri id

[fdl90]

Supponiamo che io sia un ente fruitore dell'eservice A.
Tutti i passaggi amministrativi sopra citati sono stati fatti, pertanto ho la possibilità di staccare un voucher.
Ora, supponiamo che l'eservice B abbia la stessa audience dell'eservice A e supponiamo di invocare l'eservice B con il voucher staccato per l'eservice A.
In tal caso, se l'erogatore si limita a validare la firma del voucher e i claim exp, iss e aud, la richiesta verrebbe autorizzata, sebbene i passaggi amministrativi sopra citati NON siano stati fatti, corretto?

[FedericaSicchiero]

Non è possibile invocare l'e-service B con il voucher staccato per l'e-service A, perchè anche se uso lo stesso client, la stessa chiave pubblica/privata e l'audience, gli altri dati cambiano, compresa la client assertion

[fdl90]

L'eservice B sarà esposto su una certa url che io posso recuperare dal catalogo di PDND.
Quindi, posso invocare questa url con un qualsiasi token e dovrà essere l'erogatore a bloccare la mia richiesta eventualmente.
Nello scenario che ho descritto, io userei un voucher generato da PDND per l'eservice A e, se l'audience è la stessa e il voucher non è ancora scaduto, l'eservice B autorizzerebbe la mia richiesta.
Aggiungo che non genero nessuna nuova client assertion perchè riutilizzo un voucher già staccato per un altro eservice.

[ruggerocastagnola]

Buongiorno, grazie per lo spunto interessante.

Il passaggio incriminato è questo:

Virtualmente, è possibile che ogni versione di ogni e-service abbia un'audience diversa, che solo alcune versioni dello stesso e-service abbiano la stessa audience, che diversi e-service abbiano la stessa audience.

È effettivamente ambiguo, ed è meglio rimuoverlo dalla documentazione.

Una precisazione ovvia ma importante: il token rilasciato da PDND Interoperabilità è di autenticazione, non di autorizzazione.

Dunque, per inciso: se l'erogatore usa la stessa audience per più risorse, dovrebbe avere una chiara ragione amministrativa per farlo, perché di base la risorsa che il fruitore andrà a consumare dovrebbe essere la stessa, e non dovrebbero essere necessari controlli aggiuntivi lato suo per erogare le informazioni richieste. In sostanza, dovrebbe esserci un'audience diversa per ogni servizio.

Ciò detto, se l'erogatore ha necessità di distinguere e non riesce a farlo, il problema è probabilmente nel modo in cui ha organizzato i propri servizi. Affrontare il problema con verifiche aggiuntive legate alle componenti di PDND Interoperabilità non ci sembra un buon approccio in questo caso. Per intenderci: è effettivamente possibile usare il purposeId per capire l'e-service di riferimento, ma è un uso improprio della componente. Il purposeId è un custom claim che serve per capire la finalità per la quale vengo chiamato, non come controllo stringente per fare una verifica autorizzativa sulla risorsa

[fdl90]

La sola modifica della documentazione non credo risolva il problema perchè l'audience è un campo libero, quindi idealmente posso sempre inserire un valore già esistente associato magari ad un altro eservice.

Proprio perchè il il token rilasciato da PDND Interoperabilità è di autenticazione e non di autorizzazione, vi sembra un approccio errato anche la validazione del client id tramite la relativa api di interoperabilità?

[ruggerocastagnola]

Dunque, il client id non necessariamente risolve, il fruitore potrebbe averlo associato a finalità sia per eservice A che per eservice B, è sua facoltà farlo. Posto che sì, il tema è proprio che non è l'uso previsto, questa verifica aggiuntiva.

Grazie per lo spunto anche qui, sono d'accordo che la modifica alla documentazione non risolva di per sé. Sicuramente non è una cosa che possiamo impedire in toto, da valutare il costo/beneficio se sia utile contestualmente alla creazione dell'e-service avvertire l'erogatore che sta riutilizzando un'audience

[fdl90]

Capisco che non è l'uso previsto e sono d'accordo che la validazione del solo client id non risolve completamente, però, autorizzare la richiesta solo se la chiamata https://api.uat.interop.pagopa.it/1.0/clients/clientId restituisce un 200 con la relativa response e non un 403 Insufficient privileges, garantirebbe quantomeno che quel client sia associato ad un fruitore valido che ha eseguito su PDND tutti i passaggi amministrativi citati precedentemente(creazione finalità, richiesta di fruizione, ecc)

[ruggerocastagnola]

Può essere che non abbia colto il punto, ma di base questa verifica sul client non dovrebbe essere necessaria: PDND stacca un token solamente se la catena di autorizzazioni è completa (versione di e-service attiva, richiesta di fruizione associata attiva, finalità associata attiva, client effettivamente associato a quella finalità, chiave pubblica — corrispondente alla privata con la quale è firmata l'asserzione — associata al client). L'erogatore può fare questa verifica a sua volta, come dice lei, per controprova, ma è ridondante

[fdl90]

Ho il timore che, senza quelle ulteriori validazioni, un ente possa fruire di un eservice senza richiedere la fruizione.
Basterebbe recuperare dal catalogo di PDND l'audience corrispondente all'eservice che si vuole fruire.
Creare un nuovo eservice in erogazione con quell'audience.
Richiedere internamente una fruizione per il suo stesso eservice in erogazione.
Invocare l'eservice reale con il token PDND generato.
L'erogatore riceverà un voucher valido e, limitandosi solo alla validazione di iss, exp e aud, autorizzerà la richiesta.

[ruggerocastagnola]

Solo un piccolo aggiornamento: ho riportato l'esempio al team tecnico quattro giorni fa e stiamo facendo un approfondimento sul tema