ICAR – Casi d’Uso

Dall’analisi degli elementi iniziali è stato individuato uno scenario di riferimento, a partire dal quale è possibile identificare i casi d’uso di interesse e quindi i pattern di interoperabilità da proporre.

Lo scenario di riferimento individuato vede coinvolti i seguenti attori:

• L’ente gestito (Amministrazione A) cui si fa riferimento per l’espressione
  delle esigenze tipiche e quindi dei casi d’uso. In questo contesto lo si
  può considerare un ente regione
• L’ente interlocutore (Amministrazione B) che interagisce con
  l’Amministrazione A tramite le API condivise
• AGID in qualità di fornitore del Registro Nazionale delle API, repository di riferimento per i servizi dispiegati sul territorio nazionale

A partire dallo scenario di riferimento sono stati individuati i seguenti casi d’uso:

• CU1: Pubblicazione di una API
  • Il Referente API produce l’accordo di interoperabilità da sottomettere per la pubblicazione sul Registro API Locale.
• CU2: Registrazione di una API Implementation
  • Il Referente dell’applicazione erogatrice formalizza sul registro API l’erogazione di una data API per il proprio ente.
• CU3: Adesione (Subscription) di una API Implementation
  • Il Referente dell’applicazione client formalizza sul registro API l’adesione ad una data erogazione per il proprio ente.
• CU4: Interazione applicativa in ricezione da domini esterni
  • L’applicazione client, del dominio dell’ente interlocutore, invoca il servizio sottoscritto, nel dominio dell’ente, attraverso la mediazione dell’API Gateway.
• CU5: Interazione applicativa in trasmissione verso domini esterni
  • L’applicazione client, interna al dominio dell’ente, invoca il servizio sottoscritto, nel dominio dell’ente interlocutore, attraverso la mediazione dell’API Gateway.
• CU6: Sincronizzazione con il Registro API AGID
  • L’API Registry Locale effettua la sincronizzazione, per le aree di interesse, con l’API Registry Centrale, tramite le relative API.

CU1 – Pubblicazione di una API

Il Referente API produce l’accordo di interoperabilità da sottomettere per la pubblicazione sul Registro API Locale.

Il caso d’uso vede coinvolo il Referente API che gestisce la pubblicazione della API sul Registry Locale.

Requisti

• CU1-R1: Descrizione interoperabile dell’interfaccia delle API
• CU1-R2: Definizione dei criteri di autenticazione, con specifica della sicurezza sul canale, anche differenziati per singola risorsa
• CU1-R3: Definizione dei criteri di autorizzazione, con specifica degli scope richiesti, anche differenziati per singola risorsa

Pattern

CU1-P1: Pattern OpenAPI 3 per le API REST

Questo pattern di interoperabilità soddisfa interamente i requisiti del caso d’uso nell’ambito della descrizione formale di API REST.

Come descritto più in dettaglio in seguito, l’adozione dello standard OpenAPI 3, ed in particolare dei nuovi strumenti mirati alla sicurezza degli scambi, consente di formalizzare gli aspetti di autenticazione ed autorizzazione delle richieste pervenute al servizio.

CU4 – Interazione applicativa in ricezione da domini esterni

L’applicazione client, del dominio dell’ente interlocutore, invoca il servizio sottoscritto, nel dominio dell’ente, attraverso la mediazione dell’API Gateway.

Il caso d’uso vede coinvolti l’ente gestito in qualità di erogatore di un servizio e l’ente esterno che funge da client.

Requisiti

• CU4-R1: Sicurezza Canale
  • Identificazione delle amministrazioni coinvolte Confidenzialità degli scambi
• CU4-R2: Sicurezza Messaggio
  • Identificazione degli applicativi coinvolti (mittente/destinatario dei messaggi) Integrità dei messaggi scambiati Identificazione messaggi duplicati
• CU4-R3: Non ripudio delle comunicazioni
  • Tracciatura dei dati di contesto relativi a richieste e risposte (con identità degli interlocutori) Persistenza delle evidenze dei contenuti scambiati

Pattern

Sulla base dei requisiti individuati nel caso d’uso vengono proposti i seguenti due pattern di interoperabilità:

• CU4-P1: Erogazione ModiPA
• CU4-P2: Erogazione OAuth – Client Credentials

I due pattern sono entrambi calati nel contesto delle interazioni tra due sistemi applicativi, senza il coinvolgimento dell’utente. Possono essere adottati in contesti differenti, sulla base dei requisiti richiesti. Si devono pertanto tenere presenti le caratteristiche fondamentali che distinguono i due pattern:

• Il pattern “Erogazione ModiPA”, pensato in maniera specifica per le interazioni Application-to-Application, soddisfa interamente la lista dei requisiti elencati in precedenza.

• Il pattern “Erogazione OAuth – Client Credentials”:
  • se associato al protocollo SSL con mutua autenticazione, soddisfa i requisiti sulla sicurezza del canale
  • per quanto riguarda la sicurezza messaggio, consente di soddisfare il solo requisito sull’autenticazione degli interlocutori (identificazione tramite token)
  • per quanto riguarda il non ripudio delle comunicazioni, il requisito non è soddisfatto in quanto non prevede le evidenze sui contenuti scambiati

CU5 – Interazione applicativa in trasmissione verso domini esterni

L’applicazione client, interna al dominio dell’ente, invoca il servizio sottoscritto, nel dominio dell’ente interlocutore, attraverso la mediazione dell’API Gateway.

Il caso d’uso vede coinvolti l’ente gestito in qualità di fruitore di un servizio erogato da un ente esterno.

Requisiti

• CU5-R1: Sicurezza Canale
  • Identificazione delle amministrazioni coinvolteConfidenzialità degli scambi
• CU5-R2: Sicurezza Messaggio
  • Identificazione degli applicativi coinvolti (mittente/destinatario dei messaggi) Integrità dei messaggi scambiati Identificazione messaggi duplicati
• CU5-R3: Non ripudio delle comunicazioni
  • Tracciatura dei dati di contesto relativi a richieste e risposte (con identità degli interlocutori) Persistenza delle evidenze dei contenuti scambiati
• CU5-R4: Autenticazione e Consenso dell’utente possessore dei diritti di accesso a risorse protette lato server
  • Identificazione dell’utente Propagazione dei dati identificativi dell’utente contestualmente a quelli già previsti per gli applicativi

Pattern

Sulla base dei requisiti individuati nel caso d’uso viene proposto il seguente pattern:

• CU5-P1: Fruizione ModiPA

Il pattern prevede che un applicativo interno al dominio dell’ente effettui delle invocazioni di servizio su delega di un utente il quale possiede i diritti di accesso alle relative risorse protette sul server.

Se il servizio gestore delle risorse protette fosse locale al dominio dell’ente, la relativa invocazione avverrebbe tramite autorizzazione basata sul token rilasciato al client tramite consenso dell’utente. Lo scenario attuale riguarda invece il caso in cui il servizio erogatore risieda su un dominio amministrativo esterno a quello dell’ente. Pertanto sarà necessario che la comunicazione tra i due domini

rispetti la normativa vigente in materia di interoperabilità tra sistemi della PA. Questo si traduce nell’utilizzo dell’API Gateway in grado di reperire sia le informazioni di identità dell’utente sia quelle del client mantenendo inalterata la logica di invocazione lato client. Una volta acquisita la richiesta l’API Gateway si occupa di instaurare la comunicazione con il dominio esterno erogatore in accordo alla specifica ModIPA, garantendo inoltre la propagazione delle necessarie informazioni di identità dell’utente di origine al fine di consentire i necessari controlli autorizzativi al sevizio destinatario.

RIguardo le rimanenti caratteristiche di sicurezza, legate a questo scambio, valgono le considerazioni già evidenziate per il pattern CU4-P1: Erogazione ModiPA.

• CU5-P2: Fruizione ModiPA con identificazione dell’origine compatibile con il framework di sicurezza ANPR

Questo pattern ricalca il medesimo flusso già descritto in quello precedente con la differenza che si prevede l’invio al Service Provider destinatario di un pacchetto informativo integrativo che certifichi un set di dati relativi all’effettiva origine della richiesta applicativa: utente, postazione, ufficio, ente, ecc.

In tale direzione è stato preso in esame il framework di sicurezza adottato dai comuni per l’integrazione con ANPR, nel caso di e-service SOAP. Tale framework è stato analizzato nell’ottica dell’integrazione sui flussi di comunicazione ModI, selezionando le informazioni aggiuntive e quelle ridondanti. Il pattern fornisce una soluzione specifica per il contesto del progetto ICAR.

• CU5-P3: Fruizione OAuth2 con Asserzione JWT firmata con X.509

Il pattern prevede l’accesso ad una risorsa protetta nel dominio dell’erogatore, per cui è necessario approvvigionarsi di un access token, in standard OAuth2, che certifichi l’identità dell’applicazione client in base alla relazione di trust stabilita fra i due domini coinvolti.

L’autenticazione dell’applicazione chiamante si basa sull’uso di un certificato X.509. Per ottenere l’access token è necessario autenticarsi sul dominio erogatore inviando un’asserzione JWT firmata con la chiave privata associata al certificato in trust, in accordo allo standard RFC 7523 (https://datatracker.ietf.org/doc/html/rfc7523#section-2.2).

L’API Gateway predispone l’asserzione JWT ed effettua, per conto del client reale, la negoziazione del token sul dominio erogatore. Dopo che l’Authorization Server ha validato l’asserzione viene rilasciato l’access token, con al suo interno l’identità rilevata dell’applicazione chiamante. L’identificativo del client autenticato viene riportato nel claim “azp” (Authorized Party) che, da specifica JWT, rappresenta l’entità destinataria del token rilasciato. In fase di elaborazione dell’erogatore, il valore del claim “azp” risulta essenziale per l’autenticazione del client richiedente e l’applicazione delle relative politiche di autorizzazione.

Questo pattern corrisponde a quello proposto dal Ministero del Lavoro, nell’ambito del progetto di migrazione del NCN-CO, dove i client fruitori ottengono l’access token direttamente dall’Identity Cloud Service di MLPS autenticandosi tramite un JWT firmato con la coppia di chiavi associata al certificato in trust con MLPS.

L’API Gateway invia all’erogatore l’access token JWT sull’header Authorization, in accordo alla specifica MODI, consentendo a quest’ultimo di autenticare il client tramite i dati presenti nei claim opportuni.

• CU5-P4: Fruizione API con token rilasciato da PDND

Il pattern prevede l’accesso ad una risorsa protetta nel dominio dell’erogatore, per cui è necessario approvvigionarsi di un access token, in standard OAuth2, che certifichi l’identità dell’applicazione client.
I domini coinvolti sono entrambi aderenti alla PDND, inoltre è in essere un accordo di interoperabilità che prevede che l’ente interno acceda all’API sulla base di una finalità condivisa e autorizzata.
I profili di emissione del token autorizzativo sono quelli stabiliti nella RFC 6749 (Framework OAuth 2.0). L’ente, con la stipula dell’Accordo di Interoperabilità, ha preventivamente provveduto a registrare il client utilizzatore, caricando il relativo materiale crittografico necessario all’identificazione dello stesso in fase di negoziazione del token.
L’autenticazione del client sulla PDND si basa quindi sull’uso di un certificato X.509. Per ottenere l’access token è necessario autenticarsi inviando un’asserzione JWT firmata con la chiave privata associata al certificato in trust, in accordo allo standard RFC 7523. L’asserzione inviata per richiedere il token deve comprendere le seguenti informazioni a beneficio della PDND:

• Indicazione del Client Fruitore per cui si richiede l’emissione dell’Access Token.
• Indicazione dell’Accordo di interoperabilità che abilità il Client Fruitore all’accesso all’e-service dell’Erogatore.
• Indicazione della finalità associata dal Fruitore all’Accordo di interoperabilità entro cui il Client Fruitore si impegna ad utilizzare la risposta dell’e-service dell’Erogatore.

L’API Gateway predispone l’asserzione JWT ed effettua, per conto del client reale, la negoziazione del token sulla PDND.
Dopo che la PDND ha rilasciato l’access token, con al suo interno l’identità rilevata dell’applicazione chiamante, l’API Gateway invia all’erogatore l’access token JWT sull’header Authorization, in accordo alla specifica MODI, consentendo a quest’ultimo di autenticare il client tramite i dati presenti nei claim opportuni.