org.eclipse.edc.spi.EdcException: Unable to obtain credentials: MIW API returned 401

[Julian-Marco]

We're currently working with a docker compose network containing several services, such as two different EDCs, Keycloak, Postgres, MIW and a couple of others. The MIW is connected to Keycloak and Postgres by setting the respective environment variables as well as by importing this realm into Keycloak and running this script for the database. The EDCs contain all of the SSI modules, but not anything else that is specific to the Tractus-X-EDC:

implementation("org.eclipse.tractusx.edc:ssi-miw-credential-client:0.5.1")
implementation("org.eclipse.tractusx.edc:ssi-identity-extractor:0.5.1")
implementation("org.eclipse.tractusx.edc:ssi-identity-core:0.5.1")
implementation("org.eclipse.tractusx.edc:json-ld-core:0.5.1")
implementation("org.eclipse.tractusx.edc:cx-policy:0.5.1")

All the applications start without an issue and I can succesfully connect to the Swagger UI of the MIW by authorizing with a Bearer token that I receive as a result of this command (though I suppose this isn't related to the actual problem):

curl --location 'http://keycloak:8080/realms/miw_test/protocol/openid-connect/token' \
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'client_id=miw_private_client' \
    --data-urlencode 'client_secret=miw_private_client' \
    --data-urlencode 'grant_type=password' \
    --data-urlencode 'username=catena-x' \
    --data-urlencode 'password=password' 

Unfortunately, when I start a Contract Negotation and the Consumer EDC tries to talk to the MIW, I always receive the following error:

Error logs

DEBUG 2023-10-17T11:12:36.525144133 ContractNegotiation: ID f969c4a1-7682-4ee9-a642-47de1d61b057. Attempt #1 failed to [Consumer] Send ContractRequestMessage message. Cause: Unable to obtain credentials: MIW API returned 401 org.eclipse.edc.spi.EdcException: Unable to obtain credentials: MIW API returned 401 at org.eclipse.edc.protocol.dsp.dispatcher.DspHttpRemoteMessageDispatcherImpl.lambda$dispatch$2(DspHttpRemoteMessageDispatcherImpl.java:124) at org.eclipse.edc.spi.result.AbstractResult.orElse(AbstractResult.java:105) at org.eclipse.edc.protocol.dsp.dispatcher.DspHttpRemoteMessageDispatcherImpl.dispatch(DspHttpRemoteMessageDispatcherImpl.java:124) at org.eclipse.edc.connector.core.base.RemoteMessageDispatcherRegistryImpl.dispatch(RemoteMessageDispatcherRegistryImpl.java:48) at org.eclipse.edc.connector.contract.negotiation.ConsumerContractNegotiationManagerImpl.lambda$processRequesting$0(ConsumerContractNegotiationManagerImpl.java:135) at org.eclipse.edc.statemachine.retry.CompletableFutureRetryProcess.process(CompletableFutureRetryProcess.java:50) at org.eclipse.edc.statemachine.retry.RetryProcess.execute(RetryProcess.java:71) at org.eclipse.edc.connector.contract.negotiation.ConsumerContractNegotiationManagerImpl.processRequesting(ConsumerContractNegotiationManagerImpl.java:141) at org.eclipse.edc.spi.telemetry.Telemetry.lambda$contextPropagationMiddleware$0(Telemetry.java:73) at org.eclipse.edc.statemachine.ProcessorImpl.lambda$process$1(ProcessorImpl.java:55) at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:197) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) at java.base/java.util.stream.ReduceOps$5.evaluateSequential(ReduceOps.java:258) at java.base/java.util.stream.ReduceOps$5.evaluateSequential(ReduceOps.java:248) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.ReferencePipeline.count(ReferencePipeline.java:709) at org.eclipse.edc.statemachine.ProcessorImpl.process(ProcessorImpl.java:62) at java.base/java.util.stream.ReferencePipeline$5$1.accept(ReferencePipeline.java:231) at java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1625) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:509) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:499) at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.base/java.util.stream.LongPipeline.reduce(LongPipeline.java:498) at java.base/java.util.stream.LongPipeline.sum(LongPipeline.java:456) at org.eclipse.edc.statemachine.StateMachineManager.performLogic(StateMachineManager.java:110) at org.eclipse.edc.statemachine.StateMachineManager.lambda$loop$2(StateMachineManager.java:101) at java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264) at java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) at java.base/java.lang.Thread.run(Thread.java:833)

I tried it with a couple of different configurations for the EDC, but it kinda looks like this:

tx.ssi.miw.url=http://localhost:80
tx.ssi.oauth.client.id=miw_private_client
tx.ssi.oauth.token.url=http://localhost:8080/realms/miw_test/protocol/openid-connect/token
tx.ssi.miw.authority.issuer=did:web:localhost:BPNL000000000001"
tx.ssi.oauth.client.secret.alias=secret
tx.ssi.miw.authority.id=BPNL000000000001
tx.ssi.endpoint.audience=http://localhost:7292/protocol

I'm honestly not sure whether I did it right or not but of course I tried to create a wallet and credentials first with BPNL000000000001 etc. Could the issue be related to not filling the MIW with the right values? Or is it a configuration issue on the connector side? A similar discussion can be found here but there hasn't been any answer to it and the setup is different from ours since we don't use the Sokrates and Plato connectors.

[wolf4ood]

@Julian-Marco

not sure if it's the case but is the service account enabled?
and the curl works with grant type client_credentials

[Julian-Marco]

Thanks for your answer! So you mean the curl-command should look like this?

curl --location 'http://keycloak:8080/realms/miw_test/protocol/openid-connect/token' \
    --header 'Content-Type: application/x-www-form-urlencoded' \
    --data-urlencode 'client_id=miw_private_client' \
    --data-urlencode 'client_secret=miw_private_client' \
    --data-urlencode 'grant_type=client_credentials' \
    --data-urlencode 'username=catena-x' \
    --data-urlencode 'password=password' 

Because then the Swagger UI is simply answering:

www-authenticate: Bearer error="insufficient_scope",error_description="The request requires higher privileges than provided by the access token.",error_uri="https://tools.ietf.org/html/rfc6750#section-3.1"

The curl-command I posted before does give me access to the API at least. I got it from here. Or is that one outdated?

Regarding the Service Account: Do you mean the Service Account belonging to the miw_private_client in Keycloak?

[Julian-Marco]

Thanks. I imported your realm instead and used 'grant_type=client_credentials'. This, again, gives me a valid access token and allows me to use the API via Swagger, but the error still remains the same for the Consumer-EDC.

Maybe some additional information: a couple of days ago I received a 401 error from the Swagger UI when I built the token from outside the Keycloak container. I got the hint to build it from inside the container, which solved that problem at least. So this should've been a network related issue. Could it be a similar problem in this case? Though the error message would appear kinda confusing then but who knows.

[wolf4ood]

it could be that the audience validation on MIW side is failing, i remember having this kind of issues

[Julian-Marco]

Maybe my tx.ssi.endpoint.audience is nonsense? I read somewhere that it's supposed to be the same as the edc.dsp.callback.address so I chose the same value for both, but no idea whether that's correct or not.

[wolf4ood]

no that's after the MIW request on the provider side, the 401 comes from MIW

[Julian-Marco]

it could be that the audience validation on MIW side is failing, i remember having this kind of issues

Soo, I think the part that was failing was this one:

AUTH_SERVER_URL=http://keycloak:8080

which is part of the miw.env Seems like the MIW wasn't able to resolve the address even though I put both the MIW and Keycloak (and Postgres) into the same compose network. I used my local IP address instead for both applications and the error message disappeared. I'll have to look more into it but I guess that was the main issue here.

[Julian-Marco]

As a follow-up question, now that the EDCs are able to communicate with the MIW: what's the minimalistic amount of steps I have to take to make the Provider- and Consumer-EDC communicate with each other successfully? I suppose the first step would be to create respective wallets for the Provider and Consumer, which I did by using

POST /api/wallets 

with

{
"bpn": "BPNL000000000002",
"name": "Consumer"
}

and

{
"bpn": "BPNL000000000001",
"name": "Provider"
}

and updating the connector configurations. Now I receive the following error message from the Consumer EDC:

org.eclipse.edc.spi.EdcException: Unable to obtain credentials: Cannot create a presentation from an empty credentials list

So this probably means that I have to store some VCs in my wallet first, but using

/api/wallets/{identifier}/credentials

with, say, identifier=BPNL000000000001, simply yields

Wallet BPN is not matching with request BPN(from the token)