Configurazione PDND — procedura dettagliata

Questa pagina raccoglie in un unico flusso i passi operativi per configurare l’accesso di un’organizzazione alla PDND: generazione delle chiavi, comunicazione della chiave pubblica, recupero dei parametri, caricamento delle analisi del rischio, associazione delle daily call e gestione dei casi speciali. Le tre sezioni corrispondenti nel portale sono descritte in Gestione organizzazioni.

Generazione delle chiavi

Per ciascuna delle due componenti (E-Service e API Interop) è necessario generare una coppia di chiavi:

  • chiave privata (custodita in piattaforma e non condivisa);

  • chiave pubblica (da comunicare/inserire su PDND).

Passi operativi

  1. Accedere alla piattaforma.

  2. Aprire il dettaglio dell’organizzazione, sezione Credenziali PDND.

  3. Selezionare la tipologia di chiave da generare:

    • E-Service;

    • API Interop.

  4. Generare la coppia di chiavi.

  5. Salvare/annotare:

    • identificativo chiave (se presente);

    • fingerprint (se disponibile);

    • data/ora di generazione.

Output atteso

  • chiave privata disponibile in piattaforma (non esportata in chiaro);

  • chiave pubblica esportabile in formato PEM.

Comunicare la chiave pubblica alla PDND

Per ognuna delle due tipologie (E-Service, API Interop):

  1. Accedere a PDND.

  2. Individuare la sezione di configurazione applicativa/integrazione relativa all’ente.

  3. Inserire la chiave pubblica generata.

  4. Salvare la configurazione.

Attenzione

  • Non invertire le chiavi tra E-Service e API Interop.

  • Verificare che non ci siano spazi o righe alterate durante il copia-incolla del PEM.

Recupero dei parametri da PDND

Dopo l’inserimento della chiave pubblica, dalla PDND recuperare i seguenti parametri:

  • client_id

  • client_kid

Questi parametri devono essere recuperati e conservati separatamente per E-Service e API Interop.

Checklist

  • [ ] recuperato client_id per E-Service;

  • [ ] recuperato client_kid per E-Service;

  • [ ] recuperato client_id per API Interop;

  • [ ] recuperato client_kid per API Interop.

Inserimento dei parametri in piattaforma

I parametri ricevuti dalla PDND vengono inseriti nella sezione Credenziali PDND del dettaglio organizzazione.

Passi operativi

  1. Aprire il dettaglio dell’organizzazione, sezione Credenziali PDND.

  2. Inserire per E-Service:

    • client_id;

    • client_kid.

  3. Inserire per API Interop:

    • client_id;

    • client_kid.

  4. Salvare e applicare la configurazione.

Validazioni consigliate

  • Coerenza tra client_kid e la chiave pubblica registrata.

  • Assenza di parametri scambiati tra E-Service e API Interop.

Caricamento delle analisi del rischio

Alcuni servizi/use case richiedono l’associazione a un”analisi del rischio.

Passi operativi

  1. Recuperare le analisi del rischio relative ai servizi/use case da abilitare.

  2. Aprire il dettaglio dell’organizzazione, sezione Analisi del rischio.

  3. Caricare i file/artefatti richiesti.

  4. Verificare che ogni analisi risulti:

    • correttamente caricata;

    • selezionabile in fase di associazione all’use case.

Configurazione delle daily call

Nella sezione Configurazione applicazioni del dettaglio organizzazione, per ciascun use case occorre configurare:

  • quale analisi del rischio utilizzare;

  • quale daily call associare.

Approccio consigliato

  1. Costruire una matrice di configurazione (anche in foglio di lavoro) con almeno:

    • use case;

    • tipologia (E-Service / API Interop);

    • analisi del rischio;

    • daily call.

  2. Applicare la configurazione.

Esempio di matrice (modello)

Use case

Tipo

Analisi del rischio

Daily call

<UC_1>

E-Service

<RA_1>

<DC_1>

<UC_2>

API Interop

<RA_2>

<DC_2>

Casi speciali (WAAS, ISEE)

Alcuni servizi richiedono passaggi aggiuntivi. In particolare:

  • WAAS;

  • ISEE.

Per questi servizi è necessario inviare una e-mail a INPS per richiedere l’abilitazione, prima che la configurazione risulti effettivamente attiva.

Checklist operativa

  • [ ] e-mail inviata a INPS con richiesta abilitazione;

  • [ ] conferma abilitazione ricevuta;

  • [ ] configurazione PDND completata (chiavi + parametri);

  • [ ] client_id / client_kid inseriti in piattaforma;

  • [ ] analisi del rischio associata correttamente;

  • [ ] daily call associata correttamente.

Gestione errori

Errori di autenticazione / autorizzazione

Sintomi

  • chiamate rifiutate dalla piattaforma;

  • errori riconducibili a credenziali/identità applicativa non valida.

Cause tipiche

  • client_id errato o non coerente con l’applicazione configurata;

  • client_kid non corrispondente alla chiave pubblica registrata;

  • chiave pubblica incollata in modo incompleto o alterato;

  • scambio dei parametri tra E-Service e API Interop.

Risoluzione

  1. Verificare su PDND che la chiave pubblica associata sia quella corretta.

  2. Verificare che client_id e client_kid corrispondano alla stessa configurazione.

  3. Se necessario, rigenerare le chiavi e riallineare la PDND.

Errori di configurazione use case / daily call

Sintomi

  • use case non risulta attivo o non produce i Purpose attesi;

  • limiti di chiamata non corretti o rifiuti legati al conteggio.

Cause tipiche

  • daily call associata all’use case sbagliato;

  • analisi del rischio mancante o associata in modo errato;

  • incoerenza tra tipo (E-Service/API Interop) e configurazione applicata.

Risoluzione

  1. Controllare la matrice use case ↔ analisi del rischio ↔ daily call.

  2. Verificare che l’analisi del rischio sia caricata e selezionabile.

  3. Correggere le associazioni e rieseguire la procedura.

Errori per casistiche speciali (WAAS/ISEE)

Sintomi

  • configurazione corretta ma servizio non abilitato/risponde come non autorizzato.

Cause tipiche

  • abilitazione INPS non ancora attiva o non completata.

Risoluzione

  1. Verificare lo stato della richiesta inviata a INPS.

  2. Attendere conferma e rieseguire la procedura dopo l’abilitazione.

Attenzioni operative

  • Evitare la generazione duplicata dei Purpose: prima di lanciare creazioni/recuperi, verificare se esistono già Purpose attivi per lo stesso use case.

  • Verificare sempre la corretta configurazione delle chiavi prima di procedere (coerenza chiave pubblica ↔ client_kid).

  • Controllare la coerenza tra use case, analisi del rischio e daily call: è la causa più frequente di errori «silenziosi» (configurazione formalmente valida ma operativamente errata).

  • Tenere traccia delle configurazioni con un changelog (data, operatore, modifiche).

Esecuzione e verifica post-configurazione

  1. Eseguire la procedura di recupero/gestione Purpose secondo la modalità operativa prevista.

  2. Validare i risultati:

    • Purpose creati/recuperati come atteso;

    • nessuna duplicazione;

    • associazioni use case corrette;

    • assenza di errori nei log.

  3. In caso di errore, consultare la sezione Gestione errori e ripetere solo i passi necessari.