In order to demonstrate a DataSpace, using FIWARE technologies and the i4Trust Security Framework.
The demonstrator consists of 3 participants, namend(for the sake of simplicity) One, Two and Three. Each of them has runs the following components:
- Orion-LD Context Broker to provide the standardized NGSI-LD API
- Kong as an API-Gateway, extended with FIWARE Plugins to act as Policy enforcment point(PEP) in the i4Trust framework
- Keyrock as a general IDM and as AuthorizationRegistry & Token-Endpoint in i4Trust
- Keycloak with the Keycloak-VC-Issuer Plugin as the VerifiableCredentials Issuer
- WaltId as a backend for handling DID's, VerifiableCredentials Templates and VerifiableCredentials
- VCVerifier for verification of VerifiableCredentials and as a demo-frontend to access the NGSI-LD Api
Additionally, a central TrustProvider is installed - the iShare-Satellite. Every participant is registered and identified at the satellite with an EORI and an certificate.
⚠️ All certificates and keys in this repo are generated just for the demonstrational pruposes. They have no value outside of this, therefor they are plain-text to ease the learning-curve.
The following diagramm shows the components:
In order to participate in the DataSpace, the participants have to provide certain endpoints:
- an NGSI-LD Api serving the data -> provided via Kong at
<NAME>.batterypass.fiware.dev/i4trust - a token-endpoint to exchange the iShare-compliant JWT into an access-token -> provided by Keyrock at idm-
<NAME>.batterypass.fiware.dev/oauth2/token - a delegation-endpoint to be used by Kong for policy evaluation -> provided by Keyrcok at idm-
<NAME>.batterypass.fiware.dev/ar/delegation - a trusted-list endpoint as the central trust anchor -> provided by the satellite at satellite.batterypass.fiware.dev/trusted_list
- a parties endpoint for information about the trusted parties -> provided by the satellite at satellite.batterypass.fiware.dev/parties
- a verifier supporting the SIOP-2 flow for loggin-in with a verifiable credential -> provided by VCVerifier at verifier-
<NAME>.batterypass.fiware.dev - a credentials issuer for providing VerifiableCredentials -> provided by Keycloak at kc-
<NAME>.batterypass.fiware.dev
In addition, the Keyrock-instances do provide a /ar/policy endpoint for creating policies to manage the access-control. Policies can be created, using the DelegationEvidence-Format. See the Postman-Collection for examples.
The environment supports multiple flows for authentication/authorization. Most notably, it supports both flavours of the i4Trust framework:
- logging-in using the SIOP-2 flow - see documentation on VerifiableCredentials
- logging-in using the i4Trust-traditional flow - see documentation on i4Trust Traditional
In order to ease the usage of the setup, a context-server is available at https://context.batterypass.fiware.dev/, API see the OpenAPI for the available endpoints.
Since all M2M-connections in an i4Trust environment require the usage of iShare-compliant JWT's, the ishare-jwt-helper is deployed, to serve tokens for all configured participants. The endpoint is available at [https://one.batterypass.fiware.dev/token], requiring an API-Key provided via the X-Api-Key header(see postman-collection for an example). The key is generated by Kong on startup, users logged-in to the OpenShift cluster can retrieve it via:
kubectl port-forward kong-one-kong-<POD-ID> 8001:8001 -n batterypass
curl --location --request GET 'localhost:8001/key-auths'All requests to the Policy Registry need to be authorized in an iShare-compliant way. Be aware that without further configuration, each participant is only allowed to create policies for itself, e.g. we are using the identity of ONE to access the the registry(e.g. Keyrock) of ONE. To get a valid Access Token, that for example can be used to create policies do the following:
-
Get an iShare-token:
curl --location --request GET 'one.batterypass.fiware.dev/token?clientId=EU.EORI.DEONE&idpId=EU.EORI.DEONE' \ --header 'X-Api-Key: B1cplZvgCoJQxAGgabGDZtG0JcMHLhWe'(see doc to get an API-Key) -
Exchange the JWT with an Access Token:
curl --location --request POST 'https://idm-one.batterypass.fiware.dev/oauth2/token' \ --header 'Content-Type: application/x-www-form-urlencoded' \ --data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer' \ --data-urlencode 'scope=iSHARE' \ --data-urlencode 'client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer' \ --data-urlencode 'client_assertion=<TOKEN>' \ --data-urlencode 'client_id=EU.EORI.DEONE'
The repository follows the app-of-apps approach. The batterypass-folder contains the chart for generating and configuring the ArgoCD Applications, while applications contains the individual components. In the ci-workflow the deploy command can be found, e.g. helm template ${{ secrets.OVERWRITE_VALUES }} -f values-demo.yaml . | oc -n argocd apply -f -. values-demo.yaml contains the currently deployed demo-environment configuration.