Minimum Viable Data Space
Guida al deploy e all’utilizzo in italiano
--
Introduzione
La strategia europea in materia di dati è fortemente incentrata sui concetti di Data Sharing e Data Spaces che trovano ampio spazio nei testi dei bandi e delle regolamentazioni ufficiali ( Qui e qui due articoli utili per approfondire).
Questa guida spiega come effettuare il deploy e come utilizzare un Data Space nella sua forma più minimale, così come definito dalla International Data Spaces Association. Vedremo nello specifico come scambiare un dato tra un “provider” e un “consumatore”, basandoci sull’installazione e la configurazione definita nel testbed IDS (versione 1.0, commit 502279a).
Questa guida è puramente di carattere applicativo e basata sulla nostra esperienza diretta; per una spiegazione puntuale dei singoli componenti dell’infrastruttura, si invita a far riferimento al Reference Architecture Model ufficiale.
Deployment
CA / Certificate Authority
Uno degli assunti fondamentali nell’architettura disegnata da IDSA è il fatto che all’interno del Data Space deve essere presente un’autorità che emetta i certificati per i vari partecipanti. Il testbed IDS contiene già un CA predisposto a tale scopo. Analogamente, sono presenti anche alcuni certificati di default, che vanno però convertiti in .cert. Sul nostro server utilizzato per i test eseguiamo quindi:
git clone https://github.com/International-Data-Spaces-Association/IDS-testbed/cd IDS-testbed/CertificateAuthority/data/cert# .crt + .key -> .p12openssl pkcs12 -export -out testbed1.p12 -inkey testbed1.key -in testbed1.crt -passout pass:password# .p12 -> .certopenssl pkcs12 -in testbed1.p12 -out testbed1.cert -nokeys -nodes -passin pass:password
DAPS / Dynamic Attribute Provisioning Service
Il DAPS è un componente che monitora dinamicamente l’affidabilità dei partecipanti (a differenza dei certificati, che sono statici), ed è anch’esso necessario. Essendo un componente dinamico servirà farlo girare su un server a parte. Per lanciarlo con Docker:
git clone https://github.com/International-Data-Spaces-Association/IDS-testbed/cd IDS-testbed/OmejdnDAPSdocker run -d --name omejdn -p 4567:4567 -v ./config:/opt/config -v ./keys:/opt/keys daps
Il DAPS ha bisogno di conoscere i certificati delle entità nel Data Space. Il DAPS disponibile nel testbed IDS è già configurato per accettare i certificati di default, ma se volessimo aggiungerne di nuovi è necessario seguire la procedura sotto e riavviare il DAPS:
chmod +x extensions.sh./extensions.sh> Input your certificate filename:testbed1.cert> The aki/ski extension for testbed1.cert is:66:07:ED:E5:80:E4:29:6D:1E:DD:F7:43:CA:0E:EB:38:32:C8:3A:43:keyid:07:FC:95:17:C4:95:B9:E4:AD:09:5F:07:1E:D2:20:75:2D:89:66:85nano config/clients.yml# E aggiungere questo elemento, usando come client_id quello trovato prima e come certfile il nome del file con il certificato:- client_id: 66:07:ED:E5:80:E4:29:6D:1E:DD:F7:43:CA:0E:EB:38:32:C8:3A:43:keyid:07:FC:95:17:C4:95:B9:E4:AD:09:5F:07:1E:D2:20:75:2D:89:66:85
name: Nome client di esempio
allowed_scopes:
- openid
- profile
- omejdn:api
- omejdn:write
- idsc:IDS_CONNECTOR_ATTRIBUTES_ALL
redirect_uri: http://localhost:4200
attributes:
- key: securityProfile
value: idsc:BASE_SECURITY_PROFILE
- key: referringConnector
value: http://testbed1.demo
- key: "@type"
value: ids:DatPayload
- key: "@context"
value: https://w3id.org/idsa/contexts/context.jsonld
- key: transportCertsSha256
value: c68d9e6ba3f1799bcbe5bec9d7d98b15b0ef2f292c80f6bca994178aa95ae10d certfile: testbed1.cert
Connector
Ciascuno dei partecipanti che vuole scambiare dei dati ha bisogno di un Connector, che regola lo scambio di dati e definisce le policy cui sottostare.
Prima di lanciare il nostro connector dobbiamo compilare l’immagine Docker con la configurazione “hardcodata” del DAPS: una volta clonato il repository servirà modificare il file src/main/resources/application.properties nella cartella ConnectorA e specificare l’indirizzo del DAPS (proprietà daps.url e daps.token.url). Se il Data Space è di prova, possiamo disabilitare SSL; altrimenti è preferibile abilitarlo e caricare un certificato nella cartella indicata in server.ssl.key-store.
Una volta fatte le modifiche, compiliamo con docker build -t dsc . e poi lanciamo il connector con Docker Compose:
version: '3.5'services:
postgres:
image: postgres:13
container_name: postgres
ports:
- 5432:5432
env_file:
- postgres.env
volumes:
- dataspaceconnector-data:/var/lib/postgresql/data
restart: alwaysdataspaceconnector:
image: dsc
container_name: dataspaceconnector
ports:
- 8080:8080
env_file:
- dataspaceconnector.env
volumes:
- ~/IDS-testbed/DataspaceConnectorA/src/main/resources/conf:/conf
depends_on:
- postgres
restart: alwaysui:
image: ghcr.io/international-data-spaces-association/dataspace-connector-ui:9.0.0
container_name: ui
ports:
- 8083:8083
env_file:
- ui.env
depends_on:
- dataspaceconnector
restart: alwaysvolumes:
dataspaceconnector-data: {}
con i seguenti file di configurazione:
# dataspaceconnector.envSPRING_SECURITY_USER_NAME=adminSPRING_SECURITY_USER_PASSWORD=passwordSPRING_DATASOURCE_URL=jdbc:postgresql://postgres:5432/connectordbSPRING_DATASOURCE_USERNAME=connectorSPRING_DATASOURCE_PASSWORD=12345SPRING_DATASOURCE_PLATFORM=postgresSPRING_DATASOURCE_DRIVERCLASSNAME=org.postgresql.DriverSPRING_JPA_DATABASEPLATFORM=org.hibernate.dialect.PostgreSQLDialectSERVER_SSL_ENABLED=trueSERVER_SSL_KEY-STORE=/conf/idsa-provider.jwlss.pw.p12SERVER_SSL_KEY-STORE-PASSWORD=passwordSERVER_SSL_KEY-ALIAS=1CONFIGURATION_PATH=/conf/config.jsonCAMEL_TRUSTSTORE_PATH=/conf/truststore.p12PORTAINER_APPLICATION_HOST=portainerPORTAINER_APPLICATION_PORT=9000PORTAINER_APPLICATION_USERNAME=adminPORTAINER_APPLICATION_PASSWORD=password.# postgres.envPOSTGRES_USER=connectorPOSTGRES_PASSWORD=12345POSTGRES_DB=connectordb# ui.envCONNECTOR_URL=https://172.16.2.3:8080CONNECTOR_USER=adminCONNECTOR_PASSWORD=passwordUI_TITLE=Dataspace Connector UI
Utilizzo
Immaginiamo ora uno scenario basilare con un Provider ed un Consumer.
Lato Provider proviamo a esporre sul Data Space un file chiamato database.txt.
Sul Connector del provider dovremo quindi collegarci alla porta 8083 e selezionare:
Data Offering > IDS Resources > Add resource
Le schermate che ci vengono presentate sono:
- Metadata: alcuni dati human-readable sulla risorsa; in particolare la “standard license” sarà quella che regolerà a livello contrattuale lo scambio.
- Policy: la politica di accesso al dato, tra quelle standard definite da IDSA, che il Connector dovrà applicare.
- Representation: il file da esporre e il suo MIME type.
- Catalogs: dei cataloghi locali che raggruppano le risorse.
- Brokers: qui si può registrare la risorsa su uno o più broker esterni.
Una volta creata la risorsa saremo reindirizzati alla schermata con le risorse offerte. Inizialmente nella colonna “agreements” vedremo 0, che sta a significare che non è ancora stato siglato nessun contratto di utilizzo per questa risorsa.
Proviamo ora ad accedere alla risorsa dall’altro connector, quello Consumer. Dall’interfaccia Web andiamo in Data Consumption > IDS Resources > Request Resource. Qui inseriamo l’URL del connector (che attenzione, dev’essere l’endpoint IDS-HTTP: ad esempio https://idsa-provider.jwlss.pw:8080/api/ids/data) e selezioniamo la risorsa. A questo punto ci verrà presentato il contratto stabilito del provider (nel punto 1, Metadata) e avremo la possibilità di accettarlo o meno: se lo accetteremo si creerà un agreement, e avremo accesso alla “representation”, cioè un URL che punta alla risorsa a cui accederemo tramite il connector.
Abbiamo quindi visto come creare un Data Space minimo e come utilizzarlo per scambiarsi risorse. Grazie al principio dell’interoperabilità (al centro di iniziative come GAIA-X) potremo in futuro estendere questa rete in modo semplice, installando un connector per ogni partecipante e offrendo una serie di Federation Services codificati nell’architettura IDS.
Per approfondire questo argomento vi invitiamo a consultare il Reference Architecture Model di IDSA e le implementazioni dei principali connector, Eclipse e l’IDS Reference Connector. Per qualsiasi commento o suggerimento su questa guida vi invitiamo inoltre a contattarci.
CREDITS
Questo articolo è stato scritto da Giulio Muscarello con la supervisione di Christian Racca.
Giulio è uno sviluppatore open source con la passione per l’amministrazione di sistemi Linux e cluster Kubernetes. Tra marzo e maggio ha collaborato con TOP-IX per esplorare i GAIA-X Federation Services a valore aggiunto per i Data Spaces.
Christian è Senior Engineer e Program Manager per il Consorzio TOP-IX.