Skip to content

eclipse-tractusx/managed-identity-wallet

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Managed Identity Wallets

The Managed Identity Wallets (MIW) service implements the Self-Sovereign-Identity (SSI) using did:web.

Usage

See INSTALL.md

Committer Documentation

(This section is also intentionally included in the CONTRIBUTING.md file)

The project uses the tool semantic-release to automatically create releases and manage CHANGELOG.md entries. These files SHOULD never be manually edited nor present in any PR. If you see this file in a PR, it means the incoming branch is not at the tip of the project history - it will most likely mangle your project when merged.

You'll find all important steps in the files .github/release.yaml and .releaserc.

The development work is always done on branch develop, all pull requests are made against develop. When it is time to create an official release a PR from develop to main must be created. IMPORTANT: after merging, you MUST wait for the pipeline to complete, as it will create two new commits on main. After that you MUST create a PR, merging main back into develop, to obtain these two new commits, and to kick-off the new tag on develop. Failing to do so will result in a huge headache, spaghetti code, faulty commits and other "life-improving" moments. DO NOT MESS THIS STEP UP.

It is possible to test how a release will work on your own fork, BUT you'll have to do some extra work to make it happen. semantic-release uses git notes to track the tags. You'll have to sync them manually (as most git configs do not include the settings to do so automatically):

git fetch upstream refs/notes/*:refs/notes/*
git push origin --tags
git push origin refs/notes/*:refs/notes/*

At this point your repository will behave exactly like upstream when doing a release.

Developer Documentation

To run MIW locally, this section describes the tooling as well as the local development setup.

There are two possible flows, which can be used for development:

  1. local: Run the postgresql and keycloak server inside docker. Start MIW from within your IDE (recommended for actual development)
  2. docker: Run everything inside docker (use to test or check behavior inside a docker environment)

Tooling

Following tools the MIW development team used successfully:

Area Tool Download Link Comment
IDE IntelliJ https://www.jetbrains.com/idea/download/ Useenvfile plugin to use the local flow
Build Gradle https://gradle.org/install/
Runtime Docker https://www.docker.com/products/docker-desktop/
Database DBeaver https://dbeaver.io/
IAM Keycloak https://www.keycloak.org/

Eclipse Dash Tool

Eclipse Dash Homepage

The Eclipse Dash tool is used to analyze the dependencies used in the project and ensure all legal requirements are met. We've added a gradle tasks to download the latest version of Dash locally, resolve all project dependencies and then run the tool and update the summary in the DEPENDENCIES file.

To run the license check:

./gradlew dashLicenseCheck

To clean all files created by the dash tasks:

./gradlew dashClean

This command will output all dependencies, save the to file deps.txt. Dash will read from the file and update the summary in the DEPENDENCIES file. A committer can open and issue to resolve any problems with the dependencies.

Administrator Documentation

Manual Keycloak Configuration

Within the development setup the Keycloak instance is initially prepared with the values in ./dev-assets/docker-environment/keycloak. The realm could also be manually added and configured at http://localhost:8080 via the "Add realm" button. It can be for example named localkeycloak. Also add an additional client, e.g. named miw_private_client with valid redirect url set to http://localhost:8080/*. The roles

  • add_wallets
  • view_wallets
  • update_wallets
  • delete_wallets
  • view_wallet
  • update_wallet
  • manage_app

Roles can be added under Clients > miw_private_client > Roles and then assigned to the client using Clients > miw_private_client > Client Scopes > Service Account Roles > Client Roles > miw_private_client.

The available scopes/roles are:

  1. Role add_wallets to create a new wallet
  2. Role view_wallets:
    • to get a list of all wallets
    • to retrieve one wallet by its identifier
    • to validate a Verifiable Credential
    • to validate a Verifiable Presentation
    • to get all stored Verifiable Credentials
  3. Role update_wallets for the following actions:
    • to store Verifiable Credential
    • to issue a Verifiable Credential
    • to issue a Verifiable Presentation
  4. Role update_wallet:
    • to remove a Verifiable Credential
    • to store a Verifiable Credential
    • to issue a Verifiable Credential
    • to issue a Verifiable Presentation
  5. Role view_wallet requires the BPN of Caller and it can be used:
    • to get the Wallet of the related BPN
    • to get stored Verifiable Credentials of the related BPN
    • to validate any Verifiable Credential
    • to validate any Verifiable Presentation
  6. Role manage_app used to change the log level of the application at runtime. Check Logging in the application section for more details

Overview by Endpoint

Artefact CRUD HTTP Verb/ Request Endpoint Roles Constraints
Wallets Read GET /api/wallets view_wallets
Wallets Create POST /api/wallets add_wallets 1 BPN : 1 WALLET(PER ONE [1] BPN ONLY ONE [1] WALLET!)
Wallets Create POST /api/wallets/{identifier}/credentials update_wallets
ORupdate_wallet
Wallets Read GET /api/wallets/{identifier} view_wallets OR
view_wallet
Verifiable Presentations - Generation Create POST /api/presentation update_wallets OR
update_wallet
Verifiable Presentations - Validation Create POST /api/presentations/validation view_wallets OR
view_wallet
Verifiable Credential - Holder Read GET /api/credentials view_wallets OR
view_wallet
Verifiable Credential - Holder Create POST /api/credentials update_wallet OR
update_wallet
Verifiable Credential - Holder Delete DELETE /api/credentials update_wallet
Verfiable Credential - Validation Create POST /api/credentials/validation view_wallets OR
view_wallet
Verfiable Credential - Issuer Read GET /api/credentials/issuer view_wallets
Verfiable Credential - Issuer Create POST /api/credentials/issuer update_wallets
DIDDocument Read GET /{bpn}/did.json N/A
DIDDocument Read GET /api/didDocuments/{identifier} N/A

Additionally, a Token mapper can be created under Clients > ManagedIdentityWallets > Mappers > create with the following configuration (using as an example BPNL000000001):

Key Value
Name StaticBPN
Mapper Type Hardcoded claim
Token Claim Name BPN
Claim value BPNL000000001
Claim JSON Type String
Add to ID token OFF
Add to access token ON
Add to userinfo OFF
includeInAccessTokenResponse.label ON

If you receive an error message that the client secret is not valid, please go into keycloak admin and within Clients > Credentials recreate the secret.

Development Setup

NOTE: The MIW requires access to the internet in order to validate the JSON-LD schema of DID documents.

Prerequisites

To simplify the dev environment, Taskfile is used as a task executor. You have to install it first.

IMPORTANT: Before executing any of th tasks, you have to choose your flow (local or docker). local is default. To change that, you need to edit the variable ENV in the Taskfile.yaml. (see below)

After that, run task check-prereqs to see, if any other required tool is installed or missing. If something is missing, a link to the install docs is provided.

Now, you have to adjust the env files (located in dev-assets/env-files). To do that, copy every file to the same directory, but without ".dist" at the end.

Description of the env files:

  • env.local: Set up everything to get ready for flow "local". You need to fill in the passwords.
  • env.docker: Set up everything to get ready for flow "docker". You need to fill in the passwords.

IMPORTANT: ssi-lib is resolving DID documents over the network. There are two endpoints that rely on this resolution:

  • Verifiable Credentials - Validation
  • Verifiable Presentations - Validation

The following parameters are set in env.local or env.docker file per default: ENFORCE_HTTPS_IN_DID_RESOLUTION=false MIW_HOST_NAME=localhost APPLICATION_PORT=80 If you intend to change them, the DID resolving may not work properly anymore!

IMPORTANT: When you are using macOS and the MIW docker container won't start up (stuck somewhere or doesn't start at all), you can enable the docker-desktop feature "Use Rosetta for x86/amd64 emulation on Apple Silicon" in your Docker settings (under "features in development"). This should fix the issue.

Note: SKIP_GRADLE_TASKS_PARAM is used to pass parameters to the build process of the MIW jar. Currently, it skips the tests and code coverage, but speeds up the build time. If you want to activate it, just comment it out like SKIP_GRADLE_TASKS_PARAM="" #"-x jacocoTestCoverageVerification -x test"

After every execution (either local or docker flow), run the matching "stop" task ( e.g.: task docker:start-app -> task docker:stop-app)

When you just run task without parameters, you will see all tasks available.

local

  1. Run task docker:start-middleware and wait until it shows "(main) Running the server in development mode. DO NOT use this configuration in production." in the terminal
  2. Run task app:build to build the MIW application
  3. Run ManagedIdentityWalletsApplication.java via IDE and use the local.env file to populate environment vars (e.g. EnvFile plugin for IntelliJ)
  4. Run task app:get-token and copy the token (including "BEARER" prefix) (Mac users have the token already in their clipboard)
  5. Open API doc on http://localhost:8000 (or what port you configured in the env.local file)
  6. Click on Authorize on swagger UI and on the dialog paste the token into the "value" input
  7. Click on "Authorize" and "close"
  8. MIW is up and running

docker

  1. Run task docker:start-app and wait until it shows "Started ManagedIdentityWalletsApplication in ... seconds"
  2. Run task app:get-token and copy the token (including "BEARER" prefix) (Mac users have the token already in their clipboard)
  3. Open API doc on http://localhost:8000 (or what port you configured in the env.local file)
  4. Click on Authorize on swagger UI and on the dialog paste the token into the "value" input
  5. Click on "Authorize" and "close"
  6. MIW is up and running

pgAdmin

This local environment contains pgAdmin, which is also started ( default: http://localhost:8888). The default login is:

user: pg@admin.com (you can change it in the env.* files)
password: the one you set for "POSTGRES_PASSWORD" in the env.* files

DB connection password

When you log in into pgAdmin, the local Postgresql server is already configured. But you will be asked to enter the DB password on the first time you connect to the DB. (password: POSTGRES_PASSWORD in the env.* files)

Storage folder

The storage folder of pgAdmin is mounted to dev-assets/docker-environment/pgAdmin/storage/. For example, You can save DB backups there, so you can access them on your local machine.

End Users

See OpenAPI documentation, which is automatically created from the source and available on each deployment at the /docs/api-docs/docs endpoint (e.g. locally at http://localhost:8087/docs/api-docs/docs). An export of the JSON document can be also found in docs/openapi_v001.json.

Test Coverage

Jacoco is used to generate the coverage report. The report generation and the coverage verification are automatically executed after tests.

The generated HTML report can be found under jacoco-report/html/

To generate the report run the command:

task app:test-report

To check the coverage run the command:

task app:coverage

Currently, the minimum is 80% coverage.

Common issues and solutions during local setup

1. Can not build with test cases

Test cases are written using the Spring Boot integration test frameworks. These test frameworks start the Spring Boot test context, which allows us to perform integration testing. In our tests, we utilize the Testcontainers library (https://java.testcontainers.org/) for managing Docker containers. Specifically, we use Testcontainers to start PostgreSQL and Keycloak Docker containers locally.

Before running the tests, please ensure that you have Docker runtime installed and that you have the necessary permissions to run containers.

Alternative, you can skip test during the build with ./gradlew clean build -x test

2. Database migration related issue

We have implemented database migration using Liquibase (https://www.liquibase.org/). Liquibase allows us to manage database schema changes effectively.

In case you encounter any database-related issues, you can resolve them by following these steps:

  1. Delete all tables from the database.
  2. Restart the application.
  3. Upon restart, the application will recreate the database schema from scratch.

This process ensures that any issues with the database schema are resolved by recreating it in a fresh state.

Environment Variables

name description default value
APPLICATION_PORT port number of application 8080
APPLICATION_ENVIRONMENT Environment of the application ie. local, dev, int and prod local
DB_HOST Database host localhost
DB_PORT Port of database 5432
DB_NAME Database name miw
USE_SSL Whether SSL is enabled in database server false
DB_USER_NAME Database username
DB_PASSWORD Database password
DB_POOL_SIZE Max number of database connection acquired by application 10
KEYCLOAK_MIW_PUBLIC_CLIENT Only needed if we want enable login with keyalock in swagger miw_public
MANAGEMENT_PORT Spring actuator port 8090
MIW_HOST_NAME Application host name, this will be used in creation of did ie. did:web:MIW_HOST_NAME:BPN localhost
ENCRYPTION_KEY encryption key used to encrypt and decrypt private and public key of wallet
AUTHORITY_WALLET_BPN base wallet BPN number BPNL000000000000
AUTHORITY_WALLET_NAME Base wallet name Catena-X
AUTHORITY_WALLET_DID Base wallet web did web:did:host:BPNL000000000000
VC_SCHEMA_LINK Comma separated list of VC schema URL https://www.w3.org/2018/credentials/v1, https://catenax-ng.github.io/product-core-schemas/businessPartnerData.json
VC_EXPIRY_DATE Expiry date of VC (dd-MM-yyyy ie. 01-01-2025 expiry date will be 2024-12-31T18:30:00Z in VC) 01-01-2025
KEYCLOAK_REALM Realm name of keycloak miw_test
KEYCLOAK_CLIENT_ID Keycloak private client id
AUTH_SERVER_URL Keycloak server url
ENFORCE_HTTPS_IN_DID_RESOLUTION Enforce https during web did resolution true
APP_LOG_LEVEL Log level of application INFO
AUTHORITY_SIGNING_SERVICE_TYPE Base wallet signing type, Currency only LOCAL is supported Local
LOCAL_SIGNING_KEY_STORAGE_TYPE Key storage type, currently only DB is supported DB

Technical Debts and Known issue

  1. Keys are stored in database in encrypted format, need to store keys in more secure place ie. Vault
  2. Policies can be validated dynamically as per request while validating VP and VC. Check this for more details

Logging in application

Log level in application can be set using environment variable APP_LOG_LEVEL. Possible values are OFF, ERROR, WARN, INFO, DEBUG, TRACE and default value set to INFO

Change log level at runtime using Spring actuator

We can use /actuator/loggers API endpoint of actuator for log related things. This end point can be accessible with role manage_app. We can add this role to authority wallet client using keycloak as below:

manage_app.png

  1. API to get current log settings
    curl --location 'http://localhost:8090/actuator/loggers' \
    --header 'Authorization: Bearer access_token'
  2. Change log level at runtime
    curl --location 'http://localhost:8090/actuator/loggers/{java package name}' \
    --header 'Content-Type: application/json' \
    --header 'Authorization: Bearer access_token' \
    --data '{"configuredLevel":"INFO"}'
    i.e.
    curl --location 'http://localhost:8090/actuator/loggers/org.eclipse.tractusx.managedidentitywallets' \
    --header 'Content-Type: application/json' \
    --header 'Authorization: Bearer access_token' \
    --data '{"configuredLevel":"INFO"}'

Reference of external lib

  1. https://www.testcontainers.org/modules/databases/postgres/
  2. https://github.com/dasniko/testcontainers-keycloak
  3. https://github.com/smartSenseSolutions/smartsense-java-commons
  4. https://github.com/catenax-ng/product-lab-ssi

Notice for Docker image

See Docker-hub-notice.md

Acknowledgments

We would like to give credit to these projects, which we use in our project.

semantic-release: angular

About

No description, website, or topics provided.

Resources

License

Apache-2.0, CC-BY-4.0 licenses found

Licenses found

Apache-2.0
LICENSE
CC-BY-4.0
LICENSE_non-code

Code of conduct

Security policy

Stars

Watchers

Forks

Packages

No packages published

Languages