{"id":166,"date":"2020-11-17T17:05:18","date_gmt":"2020-11-17T16:05:18","guid":{"rendered":"http:\/\/159.213.227.18\/wordpress\/?page_id=166"},"modified":"2022-04-13T17:38:13","modified_gmt":"2022-04-13T15:38:13","slug":"icar-casi-duso","status":"publish","type":"page","link":"http:\/\/159.213.227.18\/wordpress\/it\/il-progetto-icar\/icar-casi-duso\/","title":{"rendered":"ICAR &#8211; Casi d&#8217;Uso"},"content":{"rendered":"\n<p>Dall&#8217;analisi degli elementi iniziali \u00e8 stato individuato uno scenario di riferimento, a partire dal quale \u00e8 possibile identificare i casi d&#8217;uso di interesse e quindi i pattern di interoperabilit\u00e0 da proporre.<\/p>\n\n\n\n<figure class=\"wp-block-image size-large\"><img loading=\"lazy\" width=\"913\" height=\"721\" src=\"http:\/\/159.213.227.18\/wordpress\/wp-content\/uploads\/2022\/04\/scenarioICAR.png\" alt=\"\" class=\"wp-image-424\"\/><figcaption>Scenario di riferimento per il task INF-1<\/figcaption><\/figure>\n\n\n\n<p>Lo scenario di riferimento individuato vede coinvolti i seguenti attori:<\/p>\n\n\n\n<ul><li>L&#8217;ente gestito (Amministrazione A) cui si fa riferimento per l\u2019espressione<br>delle esigenze tipiche e quindi dei casi d\u2019uso. In questo contesto lo si<br>pu\u00f2 considerare un ente regione<\/li><li>L\u2019ente interlocutore (Amministrazione B) che interagisce con<br>l\u2019Amministrazione A tramite le API condivise<\/li><li>AGID in qualit\u00e0 di fornitore del Registro Nazionale delle API, repository di riferimento per i servizi dispiegati sul territorio nazionale<\/li><\/ul>\n\n\n\n<p>A partire dallo scenario di riferimento sono stati individuati i seguenti casi d\u2019uso:<\/p>\n\n\n\n<ul><li><strong>CU1: Pubblicazione di una API<\/strong><ul><li>Il Referente API produce l\u2019accordo di interoperabilit\u00e0 da sottomettere per la pubblicazione sul Registro API Locale.<\/li><\/ul><\/li><li><strong>CU2: Registrazione di una API Implementation<\/strong><ul><li>Il Referente dell\u2019applicazione erogatrice formalizza sul registro API l\u2019erogazione di una data API per il proprio ente.<\/li><\/ul><\/li><li><strong>CU3: Adesione (Subscription) di una API Implementation<\/strong><ul><li>Il Referente dell\u2019applicazione client formalizza sul registro API l\u2019adesione ad una data erogazione per il proprio ente.<\/li><\/ul><\/li><li><strong>CU4: Interazione applicativa in ricezione da domini esterni<\/strong><ul><li>L\u2019applicazione client, del dominio dell&#8217;ente interlocutore, invoca il servizio sottoscritto, nel dominio dell&#8217;ente, attraverso la mediazione dell\u2019API Gateway.<\/li><\/ul><\/li><li><strong>CU5: Interazione applicativa in trasmissione verso domini esterni<\/strong><ul><li>L\u2019applicazione client, interna al dominio dell&#8217;ente, invoca il servizio sottoscritto, nel dominio dell&#8217;ente interlocutore, attraverso la mediazione dell\u2019API Gateway.<\/li><\/ul><\/li><li><strong>CU6: Sincronizzazione con il Registro API AGID<\/strong><ul><li>L\u2019API Registry Locale effettua la sincronizzazione, per le aree di interesse, con l\u2019API Registry Centrale, tramite le relative API.<\/li><\/ul><\/li><\/ul>\n\n\n\n<h2>CU1 &#8211; Pubblicazione di una API<\/h2>\n\n\n\n<p>Il Referente API produce l\u2019accordo di interoperabilit\u00e0 da sottomettere per la pubblicazione sul Registro API Locale.<\/p>\n\n\n\n<p>Il caso d&#8217;uso vede coinvolo il Referente API che gestisce la pubblicazione della API sul Registry Locale.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img src=\"http:\/\/159.213.227.18\/wordpress\/wp-content\/uploads\/2020\/11\/image-3.png\" alt=\"This image has an empty alt attribute; its file name is image-3.png\"\/><\/figure><\/div>\n\n\n\n<h3>Requisti<\/h3>\n\n\n\n<ul><li><strong>CU1-R1: Descrizione interoperabile dell\u2019interfaccia delle API<\/strong><\/li><li><strong>CU1-R2: Definizione dei criteri di autenticazione, con specifica della sicurezza sul canale, anche differenziati per singola risorsa<\/strong><\/li><li><strong>CU1-R3: Definizione dei criteri di autorizzazione, con specifica degli scope richiesti, anche differenziati per singola risorsa<\/strong><\/li><\/ul>\n\n\n\n<h3>Pattern<\/h3>\n\n\n\n<p><strong><u>CU1-P1: Pattern OpenAPI 3 per le API REST<\/u><\/strong><\/p>\n\n\n\n<p>Questo pattern di interoperabilit\u00e0 soddisfa interamente i requisiti del caso d\u2019uso nell\u2019ambito della descrizione formale di API REST.<\/p>\n\n\n\n<p>Come descritto pi\u00f9 in dettaglio in seguito, l\u2019adozione 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.<\/p>\n\n\n\n<h2>CU4 &#8211; Interazione applicativa in ricezione da domini esterni<\/h2>\n\n\n\n<p>L\u2019applicazione client, del dominio dell&#8217;ente interlocutore, invoca il servizio sottoscritto, nel dominio dell&#8217;ente, attraverso la mediazione dell\u2019API Gateway.<\/p>\n\n\n\n<p>Il caso d&#8217;uso vede coinvolti l&#8217;ente gestito in qualit\u00e0 di erogatore di un servizio e l&#8217;ente esterno che funge da client.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img src=\"http:\/\/159.213.227.18\/wordpress\/wp-content\/uploads\/2020\/11\/image-1.png\" alt=\"This image has an empty alt attribute; its file name is image-1.png\"\/><\/figure><\/div>\n\n\n\n<h3>Requisiti<\/h3>\n\n\n\n<ul><li><strong>CU4-R1: Sicurezza Canale<\/strong><ul><li>Identificazione delle amministrazioni coinvolte Confidenzialit\u00e0 degli scambi<\/li><\/ul><\/li><li><strong>CU4-R2: Sicurezza Messaggio<\/strong><ul><li>Identificazione degli applicativi coinvolti (mittente\/destinatario dei messaggi) Integrit\u00e0 dei messaggi scambiati Identificazione messaggi duplicati<\/li><\/ul><\/li><li><strong>CU4-R3: Non ripudio delle comunicazioni<\/strong><ul><li>Tracciatura dei dati di contesto relativi a richieste e risposte (con identit\u00e0 degli interlocutori) Persistenza delle evidenze dei contenuti scambiati<\/li><\/ul><\/li><\/ul>\n\n\n\n<h3>Pattern<\/h3>\n\n\n\n<p>Sulla base dei requisiti individuati nel caso d\u2019uso vengono proposti i seguenti due pattern di interoperabilit\u00e0:<\/p>\n\n\n\n<ul><li><strong>CU4-P1: Erogazione ModiPA<\/strong><\/li><li><strong>CU4-P2: Erogazione OAuth \u2013 Client Credentials<\/strong><\/li><\/ul>\n\n\n\n<p>I due pattern sono entrambi calati nel contesto delle interazioni tra due sistemi applicativi, senza il coinvolgimento dell\u2019utente. Possono essere adottati in contesti differenti, sulla base dei requisiti richiesti. Si devono pertanto tenere presenti le caratteristiche fondamentali che distinguono i due pattern:<\/p>\n\n\n\n<ul><li>Il pattern \u201cErogazione ModiPA\u201d, pensato in maniera specifica per le interazioni Application-to-Application, soddisfa interamente la lista dei requisiti elencati in precedenza.<\/li><\/ul>\n\n\n\n<ul><li>Il pattern \u201cErogazione OAuth \u2013 Client Credentials\u201d:<ul><li>se associato al protocollo SSL con mutua autenticazione, soddisfa i requisiti sulla sicurezza del canale<\/li><li>per quanto riguarda la sicurezza messaggio, consente di soddisfare il solo requisito sull\u2019autenticazione degli interlocutori (identificazione tramite token)<\/li><li>per quanto riguarda il non ripudio delle comunicazioni, il requisito non \u00e8 soddisfatto in quanto non prevede le evidenze sui contenuti scambiati<\/li><\/ul><\/li><\/ul>\n\n\n\n<h2>CU5 &#8211; Interazione applicativa in trasmissione verso domini esterni<\/h2>\n\n\n\n<p>L\u2019applicazione client, interna al dominio dell&#8217;ente, invoca il servizio sottoscritto, nel dominio dell&#8217;ente interlocutore, attraverso la mediazione dell\u2019API Gateway.<\/p>\n\n\n\n<p>Il caso d\u2019uso vede coinvolti l\u2019ente gestito in qualit\u00e0 di fruitore di un servizio erogato da un ente esterno.<\/p>\n\n\n\n<div class=\"wp-block-image\"><figure class=\"aligncenter\"><img src=\"http:\/\/159.213.227.18\/wordpress\/wp-content\/uploads\/2020\/11\/image-2.png\" alt=\"This image has an empty alt attribute; its file name is image-2.png\"\/><\/figure><\/div>\n\n\n\n<h3>Requisiti<\/h3>\n\n\n\n<ul><li><strong>CU5-R1: Sicurezza Canale<\/strong><ul><li>Identificazione delle amministrazioni coinvolteConfidenzialit\u00e0 degli scambi<\/li><\/ul><\/li><li><strong>CU5-R2: Sicurezza Messaggio<\/strong><ul><li>Identificazione degli applicativi coinvolti (mittente\/destinatario dei messaggi) Integrit\u00e0 dei messaggi scambiati Identificazione messaggi duplicati<\/li><\/ul><\/li><li><strong>CU5-R3: Non ripudio delle comunicazioni<\/strong><ul><li>Tracciatura dei dati di contesto relativi a richieste e risposte (con identit\u00e0 degli interlocutori) Persistenza delle evidenze dei contenuti scambiati<\/li><\/ul><\/li><li><strong>CU5-R4: Autenticazione e Consenso dell&#8217;utente possessore dei diritti di accesso a risorse protette lato server<\/strong><ul><li>Identificazione dell&#8217;utente Propagazione dei dati identificativi dell&#8217;utente contestualmente a quelli gi\u00e0 previsti per gli applicativi<\/li><\/ul><\/li><\/ul>\n\n\n\n<h3>Pattern<\/h3>\n\n\n\n<p>Sulla base dei requisiti individuati nel caso d\u2019uso viene proposto il seguente pattern:<\/p>\n\n\n\n<ul><li><strong>CU<\/strong><strong>5<\/strong><strong>-P1: <\/strong><strong>Fruizione<\/strong><strong> ModiPA<\/strong><\/li><\/ul>\n\n\n\n<p>Il pattern prevede che un applicativo interno al dominio dell&#8217;ente effettui delle invocazioni di servizio su delega di un utente il quale possiede i diritti di accesso alle relative risorse protette sul server.<\/p>\n\n\n\n<p>Se il servizio gestore delle risorse protette fosse locale al dominio dell&#8217;ente, la relativa invocazione avverrebbe tramite autorizzazione basata sul token rilasciato al client tramite consenso dell&#8217;utente. Lo scenario attuale riguarda invece il caso in cui il servizio erogatore risieda su un dominio amministrativo esterno a quello dell&#8217;ente. Pertanto sar\u00e0 necessario che la comunicazione tra i due domini <\/p>\n\n\n\n<p>rispetti la normativa vigente in materia di interoperabilit\u00e0 tra sistemi della PA. Questo si traduce nell&#8217;utilizzo dell&#8217;API Gateway in grado di reperire sia le informazioni di identit\u00e0 dell&#8217;utente sia quelle del client mantenendo inalterata la logica di invocazione lato client. Una volta acquisita la richiesta l&#8217;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\u00e0 dell&#8217;utente di origine al fine di consentire i necessari controlli autorizzativi al sevizio destinatario.<\/p>\n\n\n\n<p>RIguardo le rimanenti caratteristiche di sicurezza, legate a questo scambio, valgono le considerazioni gi\u00e0 evidenziate per il pattern <strong>CU4-P1: Erogazione ModiPA.<\/strong><\/p>\n\n\n\n<ul><li><strong>CU5-P2: Fruizione ModiPA con identificazione dell\u2019origine compatibile con il framework di sicurezza ANPR<\/strong><\/li><\/ul>\n\n\n\n<p>Questo pattern ricalca il medesimo flusso gi\u00e0 descritto in quello precedente con la differenza che si prevede l\u2019invio al Service Provider destinatario di un pacchetto informativo integrativo che certifichi un set di dati relativi all\u2019effettiva origine della richiesta applicativa: utente, postazione, ufficio, ente, ecc.<\/p>\n\n\n\n<p>In tale direzione \u00e8 stato preso in esame il framework di sicurezza adottato dai comuni per l\u2019integrazione con ANPR, nel caso di e-service SOAP. Tale framework \u00e8 stato analizzato nell\u2019ottica dell\u2019integrazione sui flussi di comunicazione ModI, selezionando le informazioni aggiuntive e quelle ridondanti. Il pattern fornisce una soluzione specifica per il contesto del progetto ICAR.<\/p>\n\n\n\n<ul><li><strong>CU5-P3: Fruizione OAuth2 con Asserzione JWT firmata con X.509<\/strong><\/li><\/ul>\n\n\n\n<p>Il pattern prevede l\u2019accesso ad una risorsa protetta nel dominio dell\u2019erogatore, per cui \u00e8 necessario approvvigionarsi di un access token, in standard OAuth2, che certifichi l\u2019identit\u00e0 dell\u2019applicazione client in base alla relazione di trust stabilita fra i due domini coinvolti.<\/p>\n\n\n\n<p>L\u2019autenticazione dell\u2019applicazione chiamante si basa sull\u2019uso di un certificato X.509. Per ottenere l\u2019access token \u00e8 necessario autenticarsi sul dominio erogatore inviando un\u2019asserzione 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).<\/p>\n\n\n\n<p>L\u2019API Gateway predispone l\u2019asserzione JWT ed effettua, per conto del client reale, la negoziazione del token sul dominio erogatore. Dopo che l\u2019Authorization Server ha validato l\u2019asserzione viene rilasciato l\u2019access token, con al suo interno l\u2019identit\u00e0 rilevata dell\u2019applicazione chiamante. L\u2019identificativo del client autenticato viene riportato nel claim \u201cazp\u201d (Authorized Party) che, da specifica JWT, rappresenta l\u2019entit\u00e0 destinataria del token rilasciato. In fase di elaborazione dell\u2019erogatore, il valore del claim \u201cazp\u201d risulta essenziale per l\u2019autenticazione del client richiedente e l\u2019applicazione delle relative politiche di autorizzazione.<\/p>\n\n\n\n<p>Questo pattern corrisponde a quello proposto dal Ministero del Lavoro, nell\u2019ambito del progetto di migrazione del NCN-CO, dove i client fruitori ottengono l\u2019access token direttamente dall\u2019Identity Cloud Service di MLPS autenticandosi tramite un JWT firmato con la coppia di chiavi associata al certificato in trust con MLPS.<\/p>\n\n\n\n<p>L\u2019API Gateway invia all\u2019erogatore l\u2019access token JWT sull\u2019header Authorization, in accordo alla specifica MODI, consentendo a quest\u2019ultimo di autenticare il client tramite i dati presenti nei claim opportuni.<\/p>\n\n\n\n<ul><li><strong>CU5-P4: Fruizione API con token rilasciato da PDND<\/strong><\/li><\/ul>\n\n\n\n<p>Il pattern prevede l\u2019accesso ad una risorsa protetta nel dominio dell\u2019erogatore, per cui \u00e8 necessario approvvigionarsi di un access token, in standard OAuth2, che certifichi l\u2019identit\u00e0 dell\u2019applicazione client.<br>I domini coinvolti sono entrambi aderenti alla PDND, inoltre \u00e8 in essere un accordo di interoperabilit\u00e0 che prevede che l\u2019ente interno acceda all\u2019API sulla base di una finalit\u00e0 condivisa e autorizzata.<br>I profili di emissione del token autorizzativo sono quelli stabiliti nella RFC 6749 (Framework OAuth 2.0). L\u2019ente, con la stipula dell\u2019Accordo di Interoperabilit\u00e0, ha preventivamente provveduto a registrare il client utilizzatore, caricando il relativo materiale crittografico necessario all\u2019identificazione dello stesso in fase di negoziazione del token.<br>L\u2019autenticazione del client sulla PDND si basa quindi sull\u2019uso di un certificato X.509. Per ottenere l\u2019access token \u00e8 necessario autenticarsi inviando un\u2019asserzione JWT firmata con la chiave privata associata al certificato in trust, in accordo allo standard RFC 7523. L\u2019asserzione inviata per richiedere il token deve comprendere le seguenti informazioni a beneficio della PDND:<\/p>\n\n\n\n<ul><li>Indicazione del Client Fruitore per cui si richiede l\u2019emissione dell\u2019Access Token.<\/li><li>Indicazione dell\u2019Accordo di interoperabilit\u00e0 che abilit\u00e0 il Client Fruitore all\u2019accesso all\u2019e-service dell\u2019Erogatore.<\/li><li>Indicazione della finalit\u00e0 associata dal Fruitore all\u2019Accordo di interoperabilit\u00e0 entro cui il Client Fruitore si impegna ad utilizzare la risposta dell\u2019e-service dell\u2019Erogatore.<\/li><\/ul>\n\n\n\n<p>L\u2019API Gateway predispone l\u2019asserzione JWT ed effettua, per conto del client reale, la negoziazione del token sulla PDND.<br>Dopo che la PDND ha rilasciato l\u2019access token, con al suo interno l\u2019identit\u00e0 rilevata dell\u2019applicazione chiamante, l\u2019API Gateway invia all\u2019erogatore l\u2019access token JWT sull\u2019header Authorization, in accordo alla specifica MODI, consentendo a quest\u2019ultimo di autenticare il client tramite i dati presenti nei claim opportuni.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Dall&#8217;analisi degli elementi iniziali \u00e8 stato individuato uno scenario di riferimento, a partire dal quale \u00e8 possibile identificare i casi d&#8217;uso di interesse e quindi i pattern di interoperabilit\u00e0 da proporre. Lo scenario di riferimento individuato vede coinvolti i seguenti attori: L&#8217;ente gestito (Amministrazione A) cui si fa riferimento per l\u2019espressionedelle esigenze tipiche e quindi [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"parent":158,"menu_order":2,"comment_status":"closed","ping_status":"closed","template":"page-advanced.php","meta":[],"_links":{"self":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/pages\/166"}],"collection":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/comments?post=166"}],"version-history":[{"count":18,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/pages\/166\/revisions"}],"predecessor-version":[{"id":427,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/pages\/166\/revisions\/427"}],"up":[{"embeddable":true,"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/pages\/158"}],"wp:attachment":[{"href":"http:\/\/159.213.227.18\/wordpress\/wp-json\/wp\/v2\/media?parent=166"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}