Omejdn DAPS: Contract negotiation fails when using the EDC oauth2-daps extension

[epanagou-ubitech]

Bug Report

Description

In our setup we use omejdn-daps and we have rebuilt the ghcr.io/sovity/edc-dev:5.0.0 image with the oauth2-daps extension enabled like so:

File: launchers/common/base-prod/build.gradle.kts

  dependencies {
      // OAuth2 IAM
      api("${edcGroup}:oauth2-core:${edcVersion}")
+     api("${edcGroup}:oauth2-daps:${edcVersion}")
      api("${edcGroup}:vault-filesystem:${edcVersion}")
  }

Creating assets, usage policies and contract definitions works smoothly but contract negotiations fail.

Expected Behavior

We expect that the contract negotiation will complete.

Observed Behavior

Instead, the contract negotiation hangs and we notice the following error in the logs of the provider:

ContractNegotiation: ID 5490e9ed-3c88-4f5c-9885-2090961513e9. Fatal error while [Provider] send agreement. Error details: {"@type":"dspace:ContractNegotiationError","dspace:code":"400","dspace:reason":"Contract agreement received. Validation failed: Invalid provider credentials","dspace:processId":"a7d66e5a-33be-4d80-b42d-0cddffbb880c","@context":{"dct":"https://purl.org/dc/terms/","edc":"https://w3id.org/edc/v0.0.1/ns/","dcat":"https://www.w3.org/ns/dcat/","odrl":"http://www.w3.org/ns/odrl/2/","dspace":"https://w3id.org/dspace/v0.8/"}}

Steps to Reproduce

Steps to reproduce the behavior:

1. Add the oauth2-daps extension to build.gradle.kts (as shown above) and rebuild the image

   docker build . -f launchers/Dockerfile -t test-edc-daps
   

2. Configure docker-compose and .env

   • Generate a SKI/AKI pair and .jks file and place it in a new secrets directory at the root directory of the project.

   • At the bottom of .env put:

     EDC_IMAGE=test-edc-daps
     DAPS_URL="http://<DAPS IP AND PORT>/auth"
     EDC_OAUTH_CLIENT_ID="<YOUR CLIENT ID>"
     EDC_KEYSTORE_PASSWORD="<YOUR KEYSTORE PASSWORD>"
     

   • In docker-compose.yaml, both in edc and edc2 add:

     EDC_OAUTH_CLIENT_ID: ${EDC_OAUTH_CLIENT_ID}
     EDC_OAUTH_TOKEN_URL: ${DAPS_URL}/token
     EDC_OAUTH_PROVIDER_JWKS_URL: ${DAPS_URL}/jwks.json
     EDC_KEYSTORE: /secrets/keystore.jks
     EDC_KEYSTORE_PASSWORD: ${EDC_KEYSTORE_PASSWORD}
     EDC_OAUTH_CERTIFICATE_ALIAS: 1
     EDC_OAUTH_PRIVATE_KEY_ALIAS: 1
     

     And:

     volumes:
       - ./secrets:/secrets
     

3. Start the connectors

   docker-compose up
   

4. On the provider, create an asset and contract definition.

5. On the consumer, go to Catalog Browser, select the asset and attempt to negotiate.

6. Negotiation should hang, with the loading animation playing continuously.

7. Check the provider logs and see the Invalid provider credentials error.

Context Information

• Used version: ghcr.io/sovity/edc-dev:5.0.0 with the oauth2-daps extension, and ghcr.io/sovity/edc-ui:2.0.0 for the UI
• OS: Linux

[tmberthold]

Just a few quick notes from my side:

• for security reasons, I would strongly recommend to not rely on the Omejdn DAPS, since the last release is from June 2022 and has not been maintained since then: Link
• the image ghcr.io/sovity/edc-dev:5.0.0 is referenced in two places in the issue, this dev-version does not contain an IAM connection/extension, it uses an IAM-mock instead. Instead, the base-prod launcher is expanded in the issue, which corresponds to the actual EDC CE.
• if the goal of this issue is to connect to the MDS, then please use their current CE versions, they are currently using a sovity EDC CE v4.2.1, then we would not need to investigate this issue further: MDS Versions-Table

[epanagou-ubitech]

Thank you for the information!

We are not trying to connect to the MDS, we are trying to set up our own separate data space.
In that case, what would be a good alternative to the Omejdn DAPS?

[tmberthold]

Thank you for the information!

We are not trying to connect to the MDS, we are trying to set up our own separate data space. In that case, what would be a good alternative to the Omejdn DAPS?

I have forwarded this internally and we will get back to you about this as soon as possible.
In principle, there is also a more modern Keycloak DAPS approach if you want to use a DAPS and not a (central) MIW.

//cc: @jkbquabeck

[richardtreier]

Hi,

together with our Release v7.0.0 and this Omejdn Documentation in our Productive Deployment Guide, this issue should now be resolved. Please note that there is still a time skew issue in the Eclipse EDC that can cause Contract Negotiations to fail with certificate errors.

Please re-open the issue if your issue persists.