Esplorando PDND Interoperabilità: Best practice per la verifica del voucher
Scopriamo le best practice per verificare un voucher rilasciato di PDND e rendere sicuro l’accesso ai propri servizi
Per semplificare l’utilizzo della piattaforma PDND Interoperabilità, saranno introdotte nuove misure volte a facilitare l’applicazione delle best practice nella verifica dei voucher erogati dalla PDND, nonché nell’uso delle relative audience.
Approfondiremo:
- come un fruitore richiede ed ottiene un voucher e quali sono i claim accettati
- cosa contiene un voucher PDND
- quali sono i nuovi claim introdotti e le best practice per le verifiche
Ospiti
Stefano Perazzolo
Resp. SL PDND Interoperabilità Core
Ruggero Castagnola
Resp. SL PDND Interoperabilità Estensioni
Le risposte alle vostre domande
Il nuovo meccanismo di verifica dell’erogatore è retrocompatibile?
Sì il sistema attuale è retrocompatibile e i nuovi claim sono in aggiunta.
Dove trovo gli id?
Sia nella UI, nelle schede, che via API, chiamando le API di Interop.
Ci saranno variazioni sulla client assertion che il fruitore crea per ottenere il voucher da PDND?
Sì, saranno implementati dei controlli più stringenti. Saranno accettati solo i claim previsti. Abbiamo predisposto comunicazioni per notificare sia via PEC che via email
Noi stiamo utilizzando il purposeId insieme alle API di PDND per ricostruire il contesto della chiamata. Quel pattern resta valido?
Sì chi utilizza il purposeId per ricostruire la catena di permessi e risalire ai soggetti coinvolti può continuare ad utilizzare quegli strumenti.
I nuovi claim offrono delle modalità alternative che consentono di ridurre l’interazione con le API di PDND riducendo così le operazioni necessarie per verificare la correttezza dell’access token
Al momento recuperiamo e validiamo quei claim aggiuntivi tramite le api di interoperabilità. Abbiamo anche un meccanismo interno di caching. Possiamo continuare a usare questo approccio?
Certo. Il modello attuale, che prevede l’uso delle API di PDND, resta valido.
Quando serve aggiungere il digest e dove lo si genera ?
Il digest è utile nel flusso previsto dal profilo audit rest 02.
Crea un legame fra l’access-token di PDND e il JWT che viaggia nell’header Agid-JWT-TrackingEvidence.
Ci risulta che ci sono altri parametri nella generazione del voucher userRole*, userLoa* ,userIdpType* SACodiceFiscale, SAcodiceAUSA*, regCodicePiattaforma*, regCodiceComponente*, businessFlowID*, traceID*, spanID*
No. I parametri previsti per ottenere un access-token sono solo ed esclusivamente quelli indicati in documentazione di PDND.
Per quanto concerne il service id ed il descriptor nel caso dei fruitori ci devono essere forniti alla registrazioni dei service ?
No. Il fruitore deve limitarsi a costruire una client assertion indicando solo i campi previsti dalla documentazione.
PDND tramite le informazione di client (client_id) e finalitá (purposeId) è in grado di risalire alle catena di permessi necessari per erogare un voucher.
Se ho capito bene, non ha senso fare l'analisi del token lato fruitore, ma solo lato erogatore. Giusto?
Corretto. L’access-token è lo strumento rilasciato da PDND che il fruitore utilizza per accedere ad una risorsa di un e-service e che l’erogatore verifica per concedere l’autorizzazione.
L’analisi dell’access-token spetta quindi all’erogatore.
In che maniera si genera il JTI qualche esempio?
Il JTI è l’identificativo del JWT.
Si tratta di una stringa il cui scopo primario è identificare in maniera univoca un token.
PDND utilizza la funzione UUID4 che offre:
- Probabilità di collisione irrilevante.
- Formato già URL-safe
- Supporto out-of-the-box in quasi tutte le librerie JWT
Esistono comunque altri modi per ottenere un identificativo adatto al popolamento del campo JTI.
Considerando l'introduzione di nuovi campi e l'utilizzo dei profili ID_AUTH_CHANNEL_02 e INTEGRITY_REST_02 con ID_AUTH_REST_02, come si modifica la costruzione della client-assertion e l'ottenimento dell'access_token? possibile un esempio?
L’unico profilo che può impattare la costruzione della client-assertion è ID_AUTH_REST_02 il quale prevede il calcolo del digest da passare a PDND tramite client-assertion.
Oltre a quelli descritti nella pagina di clien-assertion, quali sono i nuovi campi da inviare per ottenere un token? C'è un esempio su selfcare, docsPagoPa o GitHub?
Quelli descritti nella documentazione di PDND sono gli unici campi necessari per l’ottenimento di un access-token.
Il fruitore dove potrà reperire i nuovi dati da inserire nella client assertion? Verranno inclusi nel wizard "Come ottengo un voucher?"
I nuovi dati non sono destinati al fruitore, ma saranno veicolati all’erogatore tramite l’access-token rilasciato da PDND.
Questi 4 nuovi campi vanno usati obbligatoriamente o sono facoltativi?
I nuovi campi offrono agli erogatori delle soluzioni alternative per semplificare le operazioni di verifica dell’access-token.
Consento inoltre di innalzare il livello di sicurezza delle verifiche nei casi in cui ,ad esempio, sono stati impostati valori di audience troppo generici.
I campi saranno sempre inseriti nel voucher di PDND, ma il loro utilizzo è demandato all’erogatore.
PDND suggerisce il loro uso per rafforzare e semplificare i controlli autorizzativi.