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.

Foto di Rakicevic Nenad: https://www.pexels.com/it-it/foto/silhouette-di-persona-in-possesso-di-vetro-mason-jar-1274260/

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 -> .p12
openssl pkcs12 -export -out testbed1.p12 -inkey testbed1.key -in testbed1.crt -passout pass:password
# .p12 -> .cert
openssl 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/OmejdnDAPS
docker 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:85
nano 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: always
dataspaceconnector:
 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: always
ui:
 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: always
volumes:
 dataspaceconnector-data: {}

con i seguenti file di configurazione:

# dataspaceconnector.env
SPRING_SECURITY_USER_NAME=admin
SPRING_SECURITY_USER_PASSWORD=password
SPRING_DATASOURCE_URL=jdbc:postgresql://postgres:5432/connectordb
SPRING_DATASOURCE_USERNAME=connector
SPRING_DATASOURCE_PASSWORD=12345
SPRING_DATASOURCE_PLATFORM=postgres
SPRING_DATASOURCE_DRIVERCLASSNAME=org.postgresql.Driver
SPRING_JPA_DATABASEPLATFORM=org.hibernate.dialect.PostgreSQLDialect
SERVER_SSL_ENABLED=true
SERVER_SSL_KEY-STORE=/conf/idsa-provider.jwlss.pw.p12
SERVER_SSL_KEY-STORE-PASSWORD=password
SERVER_SSL_KEY-ALIAS=1
CONFIGURATION_PATH=/conf/config.json
CAMEL_TRUSTSTORE_PATH=/conf/truststore.p12
PORTAINER_APPLICATION_HOST=portainer
PORTAINER_APPLICATION_PORT=9000
PORTAINER_APPLICATION_USERNAME=admin
PORTAINER_APPLICATION_PASSWORD=password.
# postgres.env
POSTGRES_USER=connector
POSTGRES_PASSWORD=12345
POSTGRES_DB=connectordb
# ui.env
CONNECTOR_URL=https://172.16.2.3:8080
CONNECTOR_USER=admin
CONNECTOR_PASSWORD=password
UI_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:

1. Metadata: alcuni dati human-readable sulla risorsa; in particolare la “standard license” sarà quella che regolerà a livello contrattuale lo scambio.
2. Policy: la politica di accesso al dato, tra quelle standard definite da IDSA, che il Connector dovrà applicare.
3. Representation: il file da esporre e il suo MIME type.
4. Catalogs: dei cataloghi locali che raggruppano le risorse.
5. 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.