Risultati
137 risultati
-
italia
3.3. Concetti di base
Interazione bloccante vs non bloccante. Nell’interazione bloccante un fruitore effettua una chiamata al servente ed attende una risposta prima di continuare l’esecuzione. La chiamata codifica in modo opportuno la richiesta di servizio, anche attraverso il passaggio di dati (sia in input alla chiamata che in output nella risposta). Nell’interazione non bloccante, invece, il fruitore invia un messaggio ma non si blocca in attesa di alcuna risposta (se non una notifica di presa in carico). Il messaggio contiene in modo opportuno la richiesta ed eventuali dati di input. Talvolta il messaggio, proprio ad indicare il fatto che codifica la richiesta e le informazioni necessarie a soddisfarla, viene indicato come documento. La risposta da parte del servente, nei casi in cui ci sia, può apparire significativamente più tardi, ove significativamente va interpretato rispetto al tempo di computazione proprio dell’interazione [2]. Anche la risposta del servente viene inviata tramite un messaggio. Con abuso di nomenclatura, la comunicazione bloccante talvolta viene detta sincrona, ad indicare che client e servente si sono sincronizzati (attesa di uno da parte dell’altro); quella non bloccante viene detta asincrona, proprio a significare l’asincronicità che vi è tra l’invio di un messaggio e la risposta al messaggio stesso. Alonso, G., Casati, F., Kuno, H., Machiraju, V. (2004). Web Services. Concepts, Architectures and Applications. Springer. . Remote Procedure Call. Una Remote Procedure Call (chiamata a procedura remota, RPC) consiste nell’attivazione, da parte di un programma, di una procedura o subroutine attivata su un elaboratore diverso da quello sul quale il programma viene eseguito. Quindi l’RPC consente a un programma di eseguire subroutine «a distanza» su elaboratori remoti, accessibili attraverso una rete. Essenziale al concetto di RPC è l’idea di trasparenza: la chiamata di procedura remota deve essere infatti eseguita in modo il più possibile analogo a quello della chiamata di procedura locale; i dettagli della comunicazione su rete devono essere «nascosti» (resi trasparenti) all’utilizzatore del meccanismo. Se il linguaggio è orientato agli oggetti, l’invocazione della procedura remote è in realtà l’invocazione di un metodo su un oggetto remoto, e si parla di Remote Method Invocation - RMI. RPC/RMI è il meccanismo base con cui realizzare una interazione bloccante. . Façade. È uno schema di organizzazione dei moduli in cui uno, detto appunto façade, maschera l’accesso ad un insieme di moduli sottostanti, ad esempio limitando l’accesso a determinate funzionalità tramite un meccanismo di gestione degli accessi, oppure nascondendo le complessità nell’organizzazione e gestione dei moduli sottostanti. . Idempotenza. Il concetto di idempotenza in matematica è una proprietà delle funzioni per la quale applicando molteplici volte una funzione data, il risultato ottenuto è uguale a quello derivante dall’applicazione della funzione un’unica volta (es. gli operatori di intersezione o unione). Applicato alle interfacce di servizio, questo concetto indica il fatto che una operazione, se eseguita più volte non comporta un risultato diverso sul sistema erogatore. Il caso classico è quello in cui si ha una operazione di creazione. Nel caso di errore di rete, l’operazione potrebbe essere eseguita senza che il fruitore riceva un messaggio di risposta. In questo caso il fruitore può ritentare la stessa operazione, ma il risultato in questo caso non deve essere la creazione di una seconda risorsa. L’erogatore dell’interfaccia di servizio deve invece riconoscere la duplicazione della richiesta ed evitare comportamenti indesiderati. Questo comportamento è solitamente ottenuto tramite l’utilizzo di correlation ID oppure tramite il confronto dati basato su dati che fungono da chiave. . Orchestrazione e coreografia. Per orchestrazione si intende un flusso di esecuzione che coinvolge diverse chiamate a servizi secondo regole prestabilite (ad es., un workflow) al fine di ottenere un servizio composto. La coreografia dei servizi è una forma di specifica della composizione dei servizi in cui il protocollo di interazione tra i diversi servizi componenti è definito da una prospettiva globale. Cioè, in fase di esecuzione della coreografia, ogni partecipante esegue la sua parte (cioè il suo ruolo) in base al comportamento degli altri partecipanti. Il ruolo specifica il comportamento, in termini di scambi di messaggi attesi dai partecipanti, che riproducono il ruolo appunto in termini di sequenziamento e tempistica dei messaggi che possono consumare e produrre. La specifica dei messaggi implica anche la descrizione dei dati scambiati tra due o più partecipanti. La differenza tra i due approcci è meglio compresa attraverso il loro confronto. Da una parte, nelle coreografie, la logica delle interazioni basate sui messaggi tra i partecipanti è specificata da una prospettiva globale. Nell’orchestrazione dei servizi, d’altra parte, la logica viene specificata dal punto di vista locale di un singolo partecipante, chiamato l’orchestratore. Nel linguaggio di orchestrazione BPEL, ad esempio, la specifica dell’orchestrazione del servizio (ad esempio il file del processo BPEL) può essere distribuita sull’infrastruttura (ad esempio un motore di esecuzione BPEL come Apache ODE), e questo costituisce l’implementazione del servizio composto. In un certo senso, le coreografie e le orchestrazioni sono due facce della stessa medaglia. Da un lato, i ruoli di una coreografia possono essere estratti come orchestrazioni attraverso un processo chiamato proiezione; attraverso la proiezione, è possibile realizzare scheletri, ovvero orchestrazioni di servizi incomplete che possono essere utilizzate come linee di base per realizzare i servizi web che partecipano alla coreografia di servizio. D’altra parte, le orchestrazioni già esistenti possono essere composte in coreografie. Chris Peltz (2003): Web Services Orchestration and Choreography. IEEE Computer 36(10):46-52. . Classificazione delle interazioni in A2A, A2C e A2B. A2A : Administration-to-Administration. A2C : Administration-to-Citizen. A2B : Administration-to-Business. In contesti di digital government, è possibile classificare le interazioni tra componenti applicativi in base al soggetto organizzativo sotto la cui responsabilità e nel cui dominio viene eseguito il componente. Si parla di Administration-to-Administration quando sia il componente servente (ad esempio l’interfaccia di servizio) che quello cliente (ad esempio, applicazione Web, applicazione mobile, un altro servizio composto che utilizza il primo come componente all’interno della propria orchestrazione, ecc.) sono nel dominio delle amministrazioni (che probabilmente saranno differenti, ma non necessariamente). Si parla di Administration-to-Citizen quando servente e cliente sono uno nel dominio dell’amministrazione e l’altro su dispositivi del privato cittadino, mentre Administration-to-Business quando servente e cliente sono uno nel dominio dell’amministrazione e l’altro di un’organizzazione privata (azienda, concessionario privato di servizi pubblici, ecc.). La distinzione è utile non tanto dal punto di vista funzionale, ma degli aspetti non funzionali, ad esempio legati al trust, alla reciprocità ed ai livelli di sicurezza che devono essere instaurati nei vari casi. . Impedance mismatch. Derivato dall”impedance mismatch dell’elettrotecnica, si riferisce alle difficoltà concettuali e tecniche che si incontrano spesso quando due paradigmi differenti, spesso implicati da altrettante tecnologie, devono coesistere e mapparsi uno sull’altro durante la progettazione e realizzazione di un sistema. Il più famoso caso di impedance mismatch è quello dell’object-to-relational, noto metaforicamente anche come il Vietnam dell’informatica [4], che si verifica quando un sistema di gestione di database relazionali (RDBMS) è servito da un programma applicativo (o da più programmi applicativi) scritto in un linguaggio di programmazione orientato agli oggetti, in particolare perché gli oggetti o le definizioni di classe devono essere associati a tabelle di database definite da uno schema relazionale. Nel ModI ci sono casi di impedance mismatch quando un’interfaccia di servizio progettata secondo lo stile RPC-like deve essere realizzata in REST. Ad es., se fruitore ed erogatore computano nell’ordine dei secondi, la risposta potrebbe arrivare dopo minuti od ore, quindi significativamente più tardi. Ad es., se fruitore ed erogatore computano nell’ordine dei secondi, la risposta potrebbe arrivare dopo minuti od ore, quindi significativamente più tardi. Cf. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/. Cf. http://blogs.tedneward.com/post/the-vietnam-of-computer-science/. ...
-
italia
2.5. Message Broker
Un message broker è un modulo software che permette l’integrazione asincrona tramite scambio di messaggi. Questo tipo di interazione è fortemente disaccoppiata perché l’invio del messaggio avviene su un canale in cui è responsabilità del message broker consegnare il messaggio ai soggetti interessati. Il compito del message broker non è però solo quello di passare dati, in quanto esso si occupa anche di aspetti legati alla sicurezza, priorità dei messaggi, inoltro ordinato. I middleware focalizzati sul fornire integrazione basata su messaggi vengono detti Message Oriented Middleware - MOM. Un message broker supporta solitamente diverse modalità di interazione:. Queuing. In questo caso un fruitore invia una richiesta su una coda specifica (corrispondente all’erogatore) e l’erogatore invia la risposta sulla medesima coda; di fatto è una realizzazione asincrona della modalità request/reply;. Store/Forward. In questo caso il broker memorizza i messaggi e quindi inoltra agli interessati. Un caso particolare di message broker è costituito dagli integration broker. Rispetto ad un message broker, questi si occupano anche della trasformazione di messaggi dai formati sorgente a quelli manipolabili dai riceventi/sottoscrittori. L’utilizzo di message broker è consigliato in alcuni casi d’uso in cui l’interazione è asincrona o di tipo publish/subscribe (ad es., Internet-of-Things - IoT, aggregatori di dati pubblici). Varie tecnologie e realizzazioni di message broker hanno storicamente supportato svariati protocolli quali STOMP [80], XMPP [81], MQTT [82], OpenWire [83] e AMPQ [84]. Oggigiorno, sebbene in determinati contesti essi vengano attualmente ancora utilizzati (ad es., in contesti intra-dominio o in casi particolari quali l’IoT in cui si preferiscono protocolli binari efficienti come MQTT), si preferiscono, in ambito di integrazione di sistemi, approcci in cui l’interfacciamento con i message broker avviene tramite interfacce di servizio REST. In particolare sono disponibili sia soluzioni native che wrapper per implementazioni di altri protocolli. I vantaggi di questo approccio includono la possibilità di utilizzare le modalità di autenticazione, autorizzazione, throttling ed accounting già discussi riguardo alla tecnologia REST, e la risoluzione di possibili problematiche legate all’attraversamento di firewall e proxy. Sebbene, a seconda delle implementazioni, le diverse interfacce di servizio REST per l’accesso a message broker differiscano per funzionalità offerte e modi di modellare code, topic/sottoscrizioni, si possono astrarre i seguenti comportamenti dei metodi HTTP:. il metodo GET viene utilizzato per consumare messaggi da code e topic/sottoscrizioni;. il metodo DELETE viene utilizzato per l’eliminazione di topic/sottoscrizioni e code ed in alcuni casi per segnalare il fatto che un messaggio è stato consumato. Il metodo PUT viene di solito utilizzato per modificare le proprietà di topic/sottoscrizioni e code. . Cf. https://stomp.github.io/. Cf. https://xmpp.org/. Cf. http://mqtt.org/. Cf. http://activemq.apache.org/openwire.html. Cf. https://www.amqp.org/ ...
-
italia
4. Sicurezza
Il presente documento descrive i profili di sicurezza individuati da AgID che i soggetti erogatori DEVONO utilizzare per soddisfare le necessità espresse attraverso requisiti funzionali e non funzionali. Data la variabilità nel tempo delle esigenze delle amministrazioni e delle tecnologie abilitanti, nonché considerata la natura incremenmtale del ModI, l’elenco dei profili di sicurezza non è da intendersi esaustivo. Nel caso in cui un’amministrazione abbia esigenze non ricoperte nei seguenti profili DEVE informare AGID e PUO” utilizzare soluzioni differenti da quelle prospettate, ma queste DEVONO garantire il medesimo o superiore livello di sicurezza. I profili individuati, coprono gli aspetti di comunicazione “sicura” tra i domini delle singole parti. Le parti mantengono la loro autonomia negli aspetti organizzativi e di sicurezza interni al proprio dominio. I profili di sicurezza. forniscono un comune linguaggio per fruitori ed erogatori utile a trattare le necessità e le caratteristiche delle interfacce di servizio. offrono agli sviluppatori le modalità tecniche supportate da standard tecnologici documentati, revisionati e testati per esporre i servizi digitali. I profili affrontano il tema della sicurezza su due livelli differenti:. Messaggio: definisce le modalità di comunicazione dei messaggi tra componenti interne dei domini delle entità coinvolte. Ogni profilo è strutturato come segue:. Descrizione: rappresentazione in linguaggio naturale del profilo con relativi precondizioni e obiettivi. Dettaglio:. Regole di processamento: elenco dei passi da eseguire per implementare il profilo. Tracciato: ove presente, fornisce un esempio dei messaggi prodotti nell’interazione. I soggetti interessati, a seguito dell’analisi dei requisiti realizzata internamente, per individuare le proprie esigenze funzionali e non funzionali, DOVREBBERO:. individuare tra i profili di sicurezza quelli che soddisfano le proprie esigenze;. implementare le interfacce di servizio attraverso la combinazione dei profili di interazione e di profili di sicurezza. L’individuazione dei profili DEVE ricoprire solamente i requisiti necessari, inoltre la scelta dei profili da implementare risulta necessaria ove l’ente erogatore del servizio non disponga già di tecnologie che garantiscano i requisiti richiesti. Trust. Il Trust è uno dei mezzi più importanti per gestire le problematiche di sicurezza nello scambio di informazione in rete per consentire l’interoperabilità tra i sistemi. Esso si basa sul reciproco riconoscimento delle entità interagenti e sulla fiducia nei rispettivi comportamenti. Nel presente documento, per direct trust, si intende la relazione di fiducia tra fruitore ed erogatore, stabilita in modalità diretta, attraverso accordi che si basano sulla condivisione del reciproco modus operandi. Tipologia di profili di sicurezza. I profili di sicurezza del presente documento sono suddivisi in due tipologie:. Autenticazione Intradominio [IDA]. Il processo di identificazione avviene all’interno del dominio di una delle due parti (fruitore ed erogatore) del direct trust. Autenticazione Extradominio [EDA]. Il processo di identificazione avviene mediante una terza parte esterna alle due parti (fruitore ed erogatore) interessate. Modalità di combinazione dei profili. I profili sono rappresentati con una sequenza di 6 caratteri:. IDA -> Autenticazione Intradominio. EDA -> Autenticazione Extradominio. il quarto carattere definisce l’ambito in cui viene gestita la problematica di sicurezza:. C: Ambito di canale ovvero livello trasporto. S: Ambito applicativo basato su tecnologia SOAP. R: Ambito applicativo basato su tecnologia REST. Gli ultimi 2 caratteri identificano univocamente il profilo. Partendo dai requisiti di sicurezza emersi durante la fase di analisi è possibile individuare il profilo di sicurezza o una combinazione di più profili di sicurezza che ricoprano le esigenze. Di seguito viene mostrata una rappresentazione dei profili attualmente presenti nel documento in cui vengono evidenziate le relazioni. mermaid.initialize({startOnLoad:true});. graph TD B(IDAC02)-->|extend|A[IDAC01] BS(IDAS02)-->|extend|AS[IDAS01] CS(IDAS03)-->|extend|AS CS-->|extend| BS BR(IDAR02)-->|extend|AR[IDAR01] CR(IDAR03)-->|extend| AR[IDAR01] CR-->|extend| BR. Fig. 4.1 Rappresentazione grafica delle dipendenze tra i profili. NOTA BENE. Le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «E’ RICHIESTO», «DOVREBBE», «NON DOVREBBE», «RACCOMANDATO», «NON RACCOMANDATO» «PUO’» e «OPZIONALE» nel testo del documento debbono essere interpretate come descritto nel seguito, in conformità alle corrispondenti traduzioni contenute nel documento IETF RFC 2119 ...
-
italia
1.1. Introduzione
Il Modello di Interoperabilità [1] (nel seguito in breve ModI) rappresenta il modello di supporto alla strategia di interoperabilità e cooperazione tra le Pubbliche Amministrazioni (di seguito PA), che definendo i contesti di interazione e integrazione tra le PA, i cittadini e le imprese permette di vedere la PA nella sua interezza come un unico sistema informativo (virtuale). La definizione del ModI deve essere coerente con il nuovo European Interoperability Framework (EIF) oggetto della Comunicazione COM (2017)134 [2] della Commissione Europea del 23 marzo 2017, al fine di assicurare anche l’interoperabilità nel contesto Europeo e per l’attuazione del Digital Single Market (Mercato Unico Digitale). Gli obiettivi del nuovo Modello di Interoperabilità sono:. armonizzare le scelte architetturali delle PA;. individuare le scelte tecnologiche che favoriscano lo sviluppo, da parte delle PA, cittadini e imprese, di soluzioni applicative innovative che abilitino l’utilizzo dei servizi individuati nelle Infrastrutture immateriali del Piano triennale per l’informatica nella PA [3];. promuovere, quando applicabile, l’adozione dell’approccio API first, al fine di favorire la separazione dei livelli di back end e front end, con logiche aperte e standard pubblici che garantiscano ad altri attori, pubblici e privati, accessibilità e massima interoperabilità di dati e servizi;. privilegiare standard tecnologici che soddisfino l’esigenza di rendere sicure le interazioni tra le PA e tra queste con i cittadini e le imprese;. semplificare le procedure di scambio di servizi tra le PA e, ove possibile, tra PA e privati, facilitando la realizzazione dei sistemi che le realizzano. . Il ModI è concettualmente la seconda versione (aggiornamento) del framework di interoperabilità della PA che nella prima versione fu definito nel 2005 con il nome di SPCoop - Servizio Pubblico di Cooperazione Applicativa, cf. http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/sistema-pubblico-connettivita/cooperazione-applicativa Il termine modello trova corrispettivo nel termine inglese framework, e pertanto nel presente documento i due termini verranno considerati sinonimi. Cf. https://ec.europa.eu/transparency/regdoc/rep/1/2017/IT/COM-2017-134-F1-IT-MAIN-PART-1.PDF. Cf. https://pianotriennale-ict.italia.it/assets/pdf/Piano_Triennale_per_l_informatica_nella_Pubblica_Amministrazione.pdf ...
-
italia
3.1. Paradigmi per la progettazione delle interfacce di servizio
Un aspetto che si vuole qui richiamare è la relazione tra l’interno e l’esterno del sistema informativo di una pubblica amministrazione, e come questo confine abbia impatti sulle interfacce di servizio in termini di funzionalità e sicurezza. Nel precedente modello di interoperabilità (il cosiddetto SPCoop del 2005) era stato definito il concetto di dominio di un’amministrazione, o dominio di cooperazione tra più amministrazioni, ad indicare l’insieme delle risorse - tra cui procedure, dati e servizi - e delle politiche di una determinata amministrazione o gruppo di amministrazioni, e rappresentava il confine di responsabilità, in particolar modo per quanto riguardava le politiche relative al sistema informativo della stessa (o gruppo di amministrazioni). Uno specifico elemento architetturale, la Porta di Dominio, istanziava fisicamente tale confine. Nel nuovo framework di interoperabilità, l’istanziazione della Porta di Dominio come punto unico di interfaccia viene meno, tuttavia concettualmente il confine del dominio dell’amministrazione continua ad esistere ed è importante considerarlo nella progettazione delle interfacce di servizio, soprattutto relativamente agli aspetti di sicurezza. Le interfacce di servizio vengono offerte da qualsiasi server applicativo, senza essere vincolate ad essere raggiungibili attraverso un unico gateway. Le figure 3.4 e 3.5 illustrano schematicamente la differenza tra i due framework. Quindi ogni server applicativo offre interfacce di servizio, tuttavia è comunque significativo distinguere se l’interfaccia di servizio viene offerta per interoperare:. all’interno del dominio (da parte di clienti applicativi offerti dalla stessa amministrazione, ad es., un’applicazione Web od una mobile). verso altre amministrazioni o altri soggetti con cui è stabilità una relazione di fiducia. esternamente, da parte di moduli applicativi completamente esterni alle pubbliche amministrazioni, e per i quali non esiste a priori nessuna relazione, né organizzativa né di fiducia. Fig. 3.4 Perimetro delle interfacce in SPCoop. Fig. 3.5 Perimetro delle interfacce in ModI. [1]. (1, 2) SOAP - Simple Object Access Protocol è il protocollo originariamente proposto, e standardizzato dal W3C, per lo sviluppo e dispiegamento di Web service. Al di sopra di esso, sono stati nel tempo proposti vari standard per Web service, ad es., WS-Addressing, WS-Discovery, WS-Federation, WS-Policy, WS-Security, and WS-Trust solo per nominarne alcuni, che oramai vengono comunemente indicati con l’acronimo WS-*. [2]. Originariamente Swagger (della società SmartBear Software) era un insieme di tool sia per la descrizione delle interfacce che per il loro sviluppo. Nel 2015 un gruppo di aziende, sotto la sponsorizzazione della Linux Foundation, ha dato vita all’iniziativa OpenAPI, a cui SmartBear ha donato il formato di specifica che è stato rinominato da Swagger Specification in OpenAPI Specification. Gli strumenti Swagger, che sono ancora supportati da SmartBear Software, sono tra gli strumenti più popolari per implementare la specifica OpenAPI e continueranno a mantenere il nome Swagger. Esistono molti altri strumenti open source e proprietari, non correlati a Swagger, che supportano la specifica OpenAPI. [3]. Cf. https://www.crummy.com/writing/speaking/2008-QCon/act3.html ...
-
italia
1.4. Scenario pregresso dell’interoperabilità nella PA
Nell’ottobre 2005 il CNIPA (oggi Agenzia per l’Italia digitale - AgID) ha pubblicato un insieme di documenti che costituiscono il riferimento tecnico per l’interoperabilità fra le PA. Tali documenti delineano il quadro tecnico-implementativo del Sistema pubblico di cooperazione (SPCoop), framework di interoperabilità a livello applicativo [8]. SPCoop ha costituito il modello concettuale ed architetturale della cooperazione applicativa tra differenti Amministrazioni e/o soggetti pubblici italiani. Tale sistema era organizzato in modo da:. essere paritetico fra tutti i soggetti cooperanti;. essere indipendente dagli assetti organizzativi dei soggetti cooperanti;. lasciare a ciascun soggetto cooperante la responsabilità dei servizi erogati e dei dati forniti;. garantire a ciascun soggetto autonomia nella gestione dei propri sistemi e nella definizione ed attuazione delle politiche di sicurezza del proprio sistema informativo;. lasciare a ciascun soggetto la responsabilità delle autorizzazioni per l’accesso ai propri dati e/o servizi. In sintesi, alla base di SPCoop vi erano i seguenti principi:. ambito di responsabilità delle singole Amministrazioni dei servizi erogati che costituiscono il Dominio di servizi applicativi della stessa Amministrazione;. accordi di servizio quale rappresentazione formale della cooperazione tra erogatore/i e fruitore/i costituiti sulla base di un fondamento normativo;. tecnologie di cooperazione: i servizi erano erogati come web service basati sugli standard che in quel momento erano consolidati ed in uso (SOAP, WSDL, UDDI). Con l’obiettivo di assicurare agli utenti di avere una visione integrata dei servizi di ogni PA, le tematiche coperte da SPCoop sono state tutte quelle che interessano l’interoperabilità dei sistemi a diversi livelli, ovvero:. catalogazione dei servizi;. semantica dei dati e dei servizi;. identità digitale. Lo scenario normativo di SPCoop è quello inquadrato dal DPCM 1 aprile 2008, recante regole tecniche e di sicurezza del Sistema pubblico di connettività (SPC), di cui SPCoop era un componente fondamentale, poi compiutamente delineato sul piano tecnico-implementativo da una suite di linee guida di seguito richiamate:. Specifiche della busta di e-gov. Specifiche della porta di dominio. Linee guida busta di e-gov. Qualificazione della porta di dominio. Qualificazione porta di dominio con concorso delle regioni. Catalogazione dei servizi. Specifiche dell’accordo di servizio. Specifiche del Registro SICA. Raccomandazioni stesura accordi di servizio. Semantica dei dati e dei servizi. Nomenclatura e semantica. Identità digitale. GFID - Gestione federata delle identità digitali. In particolare SPCoop prevedeva:. I servizi infrastrutturali per la gestione di tutti gli aspetti legati agli accordi di servizio, nel loro insieme denominati Servizi SICA, prevedevano:. Servizi di Registro: la componente, realizzata a partire dallo standard UDDI, entro cui erano registrati gli Accordi di Servizio organizzati in modo distribuito prevedendo due livelli, ovvero Generale, che contiene la totalità degli accordi di servizio, e Secondario, contenente delle viste definite secondo differenti criteri;. Catalogo degli Schemi/Ontologie, che offre gli strumenti per ragionare sulla semantica dei servizi e delle informazioni da essi veicolati;. Servizi di Sicurezza assicuravano le funzionalità per la qualificazione degli elementi del sistema e garantire gli opportuni requisiti di autenticità, riservatezza, integrità, non ripudio e tracciabilità dei messaggi scambiati. Il tempo trascorso dalla definizione del modello e il mutato quadro tecnico, organizzativo e normativo rendono necessario l’aggiornamento del modello, obiettivo appunto della presente iniziativa, come anticipato nel 2017 attraverso la Determinazione 219/2017 - Linee guida per transitare al nuovo modello di interoperabilità [9]. L’esperienza maturata con SPCoop, di seguito sintetizzata, deve essere considerata nella definizione del ModI. Cosa ha funzionato. Il coordinamento, anche delegato ad organi intermedi quali elementi di aggregazione di un insieme omogeneo di Amministrazioni, permette di favorire l’applicazione del modello condiviso. Il sistema di gestione federata delle identità digitali, nonostante si ponesse come un elemento fortemente innovativo, è stato utilizzato a livello regionale e ha consentito di disegnare su tali basi tecniche il futuro SPID. Cosa deve essere cambiato. È necessario un modello di governance che permetta di gestire le specificità dei singoli domini applicativi determinati dalle caratteristiche delle amministrazioni e dei soggetti terzi coinvolti. Cosa deve essere abbandonato. La necessità di componenti infrastrutturali disegnati per la sola Pubblica Amministrazione italiana (come Porta di Dominio e Registro SICA) determina che la spesa per il loro sviluppo ed evoluzione sia totalmente a carico della Pubblica Amministrazione. . Cf. http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/sistema-pubblico-connettivita/cooperazione-applicativa. Cf. http://www.agid.gov.it/sites/default/files/upload_avvisi/linee_guida_passaggio_nuovo_modello_interoperabilita.pdf ...
-
italia
2.7. Altri approcci e tecnologie di integrazione
Una modalità di integrazione, importante specialmente negli scenari A2B e A2C, è quella basata sull’esposizione da parte delle PA di open data. Gli open data devono essere fruibili, ed essere inseriti ove possibile nel contesto dei Base Register definiti nell”EIF [98], standardizzando gli schemi e le modalità di fruizione. Vista la progressiva crescita dei dataset, gli open data dovrebbero essere erogati in modo da ridurre gli impatti infrastrutturali sull’erogatore. Come indicato nelle linee guida nazionali per la valorizzazione del patrimonio informativo pubblico [99] pubblicate da AgID nel 2014, l’obiettivo è quello di mettere a disposizione i dati aperti in formato Linked Open Data - LOD ai fini dell’integrazione, il che prevede l’esposizione di dati in formato W3C RDF e SPARQL (secondo il cosiddetto modello del Semantic Web). A tal fine gli SPARQL endpoint costituiscono le interfacce di servizio. Le query in formato SPARQL vengono inviate su endpoint HTTP. Un altro approccio possibile, sempre nel rispetto dei dizionari comuni, è quello di utilizzare un approccio ROA basato su interfacce REST [100]. Un’interessante evoluzione dell’approccio REST (di cui eredita molti dei vantaggi, quali ad esempio la leggerezza e l’utilizzo dei verbi HTTP) che può risultare utile nell’esposizione di open data è quello basato su GraphQL [101]. In particolare, mentre per l’estrazione di dati complessi l’approccio basato su interfacce di servizio REST richiede diverse chiamate, GraphQL introduce un linguaggio che permette l’esecuzione di interrogazioni complesse sulle risorse. In tutti i casi presentati, restano valide le indicazioni contenute nelle sezioni precedenti circa la sicurezza nell’esposizione delle interfacce di servizio. [93]. Cf. https://it.wikipedia.org/wiki/Blockchain. [94]. Una rete di calcolatori si definisce peer-to-peer, quando le macchine componenti (i nodi) non sono organizzati gerarchicamente ma svolgono delle funzionalità paritarie. [95]. Cf. https://e-estonia.com/solutions/security-and-safety/ksi-blockchain. [96]. Cf. https://techcrunch.com/2018/04/19/do-you-need-a-blockchain/. [97]. Cf. https://www.multichain.com/blog/2017/05/blockchain-immutability-myth/. [98]. Cf. https://joinup.ec.europa.eu/asset/eia/description. [99]. Cf. http://lg-patrimonio-pubblico.readthedocs.io/it/latest/index.html. [100]. Cf. Massimo Mecella, Francesco Leotta (2017): Migliorare l’accesso agli open data pubblici: tecnologie e approcci, https://www.agendadigitale.eu/cittadinanza-digitale/pa-tecnologie-e-approcci-per-migliorare-laccesso-ai-dati-aperti/. [101]. Cf. https://graphql.org/ ...
-
italia
1.3. Il quadro di riferimento attuale
Il Piano triennale per l’informatica nella PA [7] costituisce il quadro di riferimento entro cui si colloca il ModI all’interno del Modello strategico di evoluzione del sistema informativo della PA. . Figura 4 - Piano triennale per l’informatica nella PA. Il modello strategico, pensato per superare l’approccio a «silos», storicamente adottato dalla PA, mira a favorire la realizzazione di un sistema informativo unitario della PA ed è caratterizzato da:. definiscono regole comuni per la progettazione di interfacce, servizi e contenuti, migliorando e rendendo coerente la navigazione e l’esperienza del cittadino e delle imprese;. facilitano il design, la realizzazione e la diffusione di servizi digitali;. definiscono linee guida e kit di sviluppo;. provvedono alla creazione di community di sviluppatori, di designer e di chiunque voglia scambiare informazioni, collaborare e partecipare. Gli Ecosistemi, sono i settori o le aree omogenee in cui si svolge l’azione da parte delle PA. Ciascun ecosistema coinvolge enti e organismi pubblici, e soggetti privati che operano nella stessa area di interesse e che a vario titolo svolgono funzioni attive all’interno dell’ecosistema stesso. I soggetti interessati interagiscono per il raggiungimento di obiettivi comuni attraverso. la condivisione delle esigenze e delle modalità operative;. la condivisione delle differenti competenze;. la pianificazione e la realizzazione di progetti ICT. Il Modello di Interoperabilità, definisce i meccanismi che facilitano e garantiscono la corretta interazione tra gli attori del sistema (cittadini, imprese e PA), favorendo la condivisione trasparente di dati, informazioni, piattaforme e servizi. Il Modello di Interoperabilità è costituito da linee guida, standard tecnologici e profili di interoperabilità che ciascuna PA dovrà seguire al fine di garantire l’interoperabilità dei propri sistemi con quelli di altri soggetti per l’implementazione complessiva del Sistema informativo della PA. Le Infrastrutture immateriali e il Data & Analytics Framework (DAF) della PA, che incentivano la centralizzazione e la razionalizzazione dei sistemi per la gestione dei processi e dei dati, riducendo la frammentazione degli interventi. In particolare, le Infrastrutture immateriali facilitano, standardizzano e razionalizzano la creazione di servizi ICT e sono composte dalle Piattaforme abilitanti e dai Dati della PA:. nelle piattaforme abilitanti ricadono tutti quei servizi infrastrutturali (eg. servizio di identificazione, servizio di pagamenti, ANPR) che agevolano e riducono i costi per la realizzazione di nuovi servizi uniformando gli strumenti utilizzati dagli utenti finali durante la loro interazione con la PA;. relativamente ai dati della PA si distinguono: le basi di dati di interesse nazionale, gli open data, e i vocabolari controllati. Il Data & Analytics Framework è un ambiente centralizzato che acquisisce e rende più fruibili i dati pubblici di interesse e ha l’obiettivo (i) di rendere più semplice e meno onerosa l’interoperabilità dei dati pubblici tra PA e la distribuzione e standardizzazione dei dati aperti (open data) e (ii) di permettere lo studio dei fenomeni sottostanti ai dati pubblici. Le Infrastrutture fisiche, che perseguono l’obiettivo di aumentare la sicurezza, ridurre il costo delle infrastrutture tecnologiche e migliorare la qualità dei servizi software della PA, attraverso la razionalizzazione dei data center, l’adozione sistematica del paradigma cloud e lo sviluppo della connettività, con particolare riferimento alla rete Internet nei luoghi pubblici e negli uffici della PA. La Sicurezza che comprende:. le attività per la regolazione e regolamentazione della cyber-security nella PA per l”assessment test,. il CERT-PA quale strumento operativo per supportare l’adozione dei corretti livelli di sicurezza presso le PA. La Gestione del cambiamento che è una componente definita per far fronte alle necessità di coordinamento, gestione e monitoraggio delle attività funzionali allo sviluppo del Piano. . Cf. https://pianotriennale-ict.italia.it/ ...
-
italia
3.2. Profili di Interazione
Il profilo di interazione definisce le modalità secondo le quali un fruitore ed un erogatore possono interagire, l’interazione avviene definendo le interfacce di servizio. I profili di interazione quali riferimenti concettuali coniugano, fatto salvo per l’accesso CRUD, message exchange pattern (MEP) per le tecnologie SOAP e REST proposte dal ModI. Di seguito l’attenzione è rivolta agli aspetti funzionali rimandando per gli aspetti di sicurezza all’apposito documento delle linee guida. Per i concetti di bloccante e non bloccante si rimanda alla lettura di «Concetti di base». Ogni interfaccia di servizio deve essere rappresentata mediante un IDL - Interface Description Language standard - che il ModI fissa:. per le interfacce di servizio SOAP, WSDL 1.1 e successive. L’endpoint deve indicare in modo esplicito la tecnologia utilizzata (REST o SOAP) e la versione (versioning su URL). ...
-
italia
3. Profili e Raccomandazioni
La terza sezione del Modello di Interoperabilità, così come introdotto nella sezione relativa alla visione generale, fornisce indicazioni concrete, a livello tecnico, su differenti modalità operative per realizzare l’interoperabilità tra sistemi informativi di differenti pubbliche amministrazioni, tenendo conto delle possibili tecnologie ed approcci disponibili. Data la veloce evoluzione tecnologica, questo documento verrà continuamente aggiornato ed approfondito. Questa versione si focalizza sulle modalità bloccanti e non bloccanti e sulle tecnologie SOAP e REST. La sezione è organizzata nel seguente modo:. 3.2 - Profili di interazione descrive i profili di interoperabilità proposti, adottando uno stile uniforme di presentazione a scheda, in modo da rendere agevole e di immediata fruibilità la consultazione. 3.3 - Concetti di base presenta ulteriori concetti architetturali che vengono richiamati nel documento, insieme alla bibliografia di riferimento, sia per motivi di autocontenimento che di disambiguazione. 3.4 - Riferimenti Bibliografici. NOTA BENE. Le parole chiave «DEVE», «DEVONO», «NON DEVE», «NON DEVONO», «E” RICHIESTO», «DOVREBBE», «NON DOVREBBE», «RACCOMANDATO», «NON RACCOMANDATO» «PUO”» e «OPZIONALE» nel testo del documento debbono essere interpretate come descritto nel seguito, in conformità alle corrispondenti traduzioni contenute nel documento IETF RFC 2119 ...
-
italia
2.4. REST
Nelle API basate su REST, meccanismi di throttling vengono implementati al fine di garantire l’accessibilità delle interfacce di servizio ed evitare in alcuni casi la raccolta non autorizzata (web-harvesting) dei dati. Poiché l’RFC 6585 prevede per la gestione del throttling il solo status code 429, nel Modl si richiede di notificare al fruitore lo stato del throttling ed eventuali limiti come segue:. restituire in ogni risposta valida i valori globali di throttling tramite i seguenti header HTTP:. X-RateLimit-Limit: limite massimo di richieste per un endpoint;. X-RateLimit-Remaining: numero di richieste rimanenti fino al prossimo reset;. X-RateLimit-Reset: il numero di secondi mancanti al momento in cui il limite verrà reimpostato. utilizzare gli HTTP status code nelle risposte:. HTTP 429 (too many requests), insieme ai rate limit di cui al punto precedente, se il rate limit viene superato;. HTTP 503 (service unavailable) se l’infrastruttura non può erogare le operazioni offerte nei tempi attesi (definiti dalla SLA associata all’interfaccia di servizio). nei casi 429 e 503 gli erogatori dovrebbero notificare al client dopo quanti secondi ripresentarsi tramite l’header Retry-After [78] (pratica anche detta “circuit breaker”), anche implementando meccanismi di exponential back-off. L’RFC prevede che questo header possa essere utilizzato sia in forma di data che di secondi, ma il Modl vieta l’utilizzo del formato data poiché se non implementato correttamente potrebbe aggravare lo stato dei sistemi. I fruitori dell’interfaccia di servizio devono impegnarsi a rispettare le indicazioni provenienti dagli header e dagli status code di cui sopra. [55]. Cf. http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm. [56]. Cf. Sam Newman (2015): Building Microservices. [57]. Cf. https://www.openapis.org/. [58]. Si supponga ad esempio una operazione HTTP GET http://api.domain.com/management/departments che restituisce informazioni circa i reparti. Il singolo reparto può contenere link relativi ad altre operazioni come quella per ottenere gli impiegati del reparto:{«departmentId»: 10,»departmentName»: «Administration»,»links»: [{«href»: «[[http://api.domain.com/management/departments/10/employees]{.underline}](http://api.domain.com/management/departments/10/employees)»,»rel»: «employees», «type» : «GET» }]}. [59]. Cf. https://tools.ietf.org/html/rfc7231#section-4.3. [60]. C.f. https://en.wikipedia.org/wiki/Optimistic_concurrency_contro. [61]. Cf. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/ETag. [62]. Cf. http://www.etsi.org/deliver/etsi_ts/118100_118199/118103/02.04.01_60/ts_118103v020401p.pdf. [63]. Cf. http://www.agid.gov.it/agenda-digitale/infrastrutture-architetture/cert-pa/linee-guida-sviluppo-sicuro. [64]. Cf. http://www.etsi.org/deliver/etsi_ts/133100_133199/133180/14.02.00_60/ts_133180v140200p.pdf. [65]. Cf. https://tools.ietf.org/html/rfc7519. [66]. Cf. https://tools.ietf.org/html/rfc7515. [67]. Cf. https://tools.ietf.org/html/rfc7516. [68]. Lo schema Bearer, inizialmente introdotto nella specifica OAuth2 ma poi utilizzato in altri contesti, ha la forma «Authorization: Bearer
» dove il token JWT è codificato in base64. [69]. Cf. https://www.owasp.org/index.php/REST_Security_Cheat_Sheet. [70]. Cf. https://www.owasp.org/index.php/OWASP_API_Security_Project. [71]. Cf. https://tools.ietf.org/html/rfc7515#section-10. [72]. Cf. https://tools.ietf.org/html/rfc3986. [73]. Cf. https://linee-guida-cataloghi-dati-profilo-dcat-ap-it.readthedocs.io/it/latest/catalogo_elementi_obbligatori.html#titolo-dct-title Ad esempio,. sono ammesse stringhe come «id», «args» o «stdin» ed abbreviazioni come «tcp» ed «udp»;. stringhe come «codice fiscale» andrebbero espresse per esteso con «codice_fiscale» o «tax_code», e non con «cod_fiscale», «cod_fisc» o «cf». [74]. Alcune indicazioni in questo senso:. usare parole minuscole separate da trattino «-«;. usare nomi al plurale per le risorse e al singolare per l’accesso alla singola risorsa;. ispirarsi alle convenzioni utilizzate a livello europeo (ad es., Core Vocabularies/Dizionari Controllati, Direttiva Europea INSPIRE 2007/2/CE);. non contenere verbi (ad es., api.example.com/ospedale/prenota/);. uniformarsi a quello di altre interfacce di servizio a livello Europeo quando ciò vada nella direzione dell’interoperabilità e della semplicità. In generale tutte le stringhe in inglese dovrebbero utilizzare la dizione US per evitare ambiguità (come ad es., «color» vs «colour», «flavor» vs «flavour»). [75]. Cf. https://tools.ietf.org/html/rfc7159. [76]. Cf. https://tools.ietf.org/html/rfc7807. [77]. Cf. http://www.iana.org/assignments/link-relations/link-relations.xml. [78]. Cf. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Retry-After. [1]. Originariamente Swagger (della società SmartBear Software) era un insieme di tool sia per la descrizione delle interfacce che per il loro sviluppo. Nel 2015 un gruppo di aziende, sotto la sponsorship della Linux Foundation, ha dato vita all’iniziativa OpenAPI, a cui SmartBear ha donato il formato di specifica che è stato rinominato da Swagger Specification in OpenAPI Specification. OpenAPI 3.0 è l’ultima versione della specifica. Gli strumenti Swagger, che sono ancora supportati da SmartBear Software, sono tra gli strumenti più popolari per implementare la specifica OpenAPI e continueranno a mantenere il nome Swagger. Esistono molti altri strumenti open source e proprietari, non correlati a Swagger, che supportano la specifica OpenAPI ... -
italia
8. Robustezza
Gli SLI pubblicati DEVONO:. utilizzare unità di misure referenziate dal Sistema Internazionale (ad esempio, secondi o bytes);. indicare nel nome identificativo l’eventuale periodo di aggregazione con i soli suffissi s (secondi), m (minuti), d (giorni) e y (anni), utilizzando al posto dei mesi il numero di giorni;. includere la latenza aggiuntiva dovuta ad eventuali componenti infrastrutturali e di rete (ad esempio, proxy o gateway). Gli SLO e gli SLA DOVREBBERO essere in relazione diretta con i valori associati (ad esempio, indicare il success rate anziché l’error rate), in modo che a valori più alti corrispondano risultati positivi. Alcuni esempi di indicatori a cui è possibile associare degli obiettivi o degli accordi:. dimensione massima di ogni richiesta accettata. Le richieste più grandi possono essere rifiutate. latenza al 90º percentile. Utilizzata per calcolare la responsività. percentuale di minuti negli ultimi 30 giorni in cui l’interfaccia di servizio è stata disponibile. valori a 30 giorni del success rate, ovvero il numero di chiamate terminate con successo rispetto al numero totale di chiamate. Application Performance inDEX [3], indice su scala percentuale di qualità del servizio misurato a 30 giorni. tempo di risposta medio delle richieste totali (includendo le richieste rifiutate a causa del throttling) negli ultimi 30 giorni. throughput misurato in byte/s. [1]. È in corso il processo di standardizzazione dell’utilizzo degli header indicati https://datatracker.ietf.org/doc/draft-ietf-httpapi-ratelimit-headers/. [2]. Cfr. RFC 7231 prevede che l’header HTTP header Retry-After possa essere utilizzato sia in forma di data che di secondi. [3]. Cf. https://en.wikipedia.org/wiki/Apdex ...