Failed to Run the Example for sts-server

[harnvo]

Bug Report

Describe the Bug

Following the example given in launchers/sts-server/README.md gives unexpected output.

After building a runtime and setting up cert and private keycorrectly, I ran the following command as is documented in the README:

curl --request POST \
  --url http://localhost:9292/api/v1/sts/token \
  --header 'Content-Type: application/x-www-form-urlencoded' \
  --data grant_type=client_credentials \
  --data client_id=testClient \
  --data client_secret=clientSecret \
  --data audience=test10 

Expected Behavior

I should get the token.

Observed Behavior

Instead it returns :

{"error":"invalid_client","error_description":"Invalid client or Invalid client credentials"}

Steps to Reproduce

Follow the tutorial given in launchers/sts-server/README.md

Context Information

Add any other context about the problem here.

• Used version: EDC v0.7.0
• OS: Debian12
• Java version- 17
• Gradle- 8.6
• ...

Possible Cause

By looking at the debug information provided by monitor in Vault, I found the method storeSecret has never been called.
This means the vault in StaClientServiceImpl does not contain sts-vault.properties as expected (it doea not contain any key-value pairs!).
Probably a slight change in -D could fix this issue, but since the project uses injection to create the Service and that I am not familiar with the injection framework, I cannot dig deeper.

[github-actions]

Thanks for your contribution 🔥 We will take a look asap 🚀

[wolf4ood]

Hi @harnvo

thanks for raising this, the main issue is the removal of the filesystem vault that happened in #4202.

The config file sts-vault.properties basically it's not used now. We'd have to change the README and change how to seed the vault.

Thanks

[harnvo]

I later tried manually adding vault.storeSecret("secretAlias", "clientSecret"); during initialization of StsClientServiceImpl, but running the example gives me the following output:

DEBUG 2024-06-20T22:31:00.840818906 Resolving secret secretAlias
DEBUG 2024-06-20T22:31:00.844244755 Resolving secret 1
DEBUG 2024-06-20T22:31:00.845082662 [PrivateKeyResolution] Public key not found, fallback to config. Error: Private key with ID '1' not found in Vault
SEVERE 2024-06-20T22:31:00.847577119 JerseyExtension: Unexpected exception caught
java.lang.NullPointerException: Cannot invoke "java.util.function.Function.apply(Object)" because "failureAction" is null
        at org.eclipse.edc.spi.result.AbstractResult.orElse(AbstractResult.java:105)
        at org.eclipse.edc.iam.identitytrust.sts.defaults.StsDefaultServicesExtension.lambda$clientTokenService$1(StsDefaultServicesExtension.java:71)
        at org.eclipse.edc.iam.identitytrust.sts.defaults.service.StsClientTokenGeneratorServiceImpl.lambda$tokenFor$0(StsClientTokenGeneratorServiceImpl.java:58)
        at org.eclipse.edc.token.JwtGenerationService.generate(JwtGenerationService.java:45)
        at org.eclipse.edc.iam.identitytrust.sts.embedded.EmbeddedSecureTokenService.lambda$createToken$1(EmbeddedSecureTokenService.java:74)
        at org.eclipse.edc.spi.result.AbstractResult.compose(AbstractResult.java:185)
        at org.eclipse.edc.iam.identitytrust.sts.embedded.EmbeddedSecureTokenService.createToken(EmbeddedSecureTokenService.java:72)
        at org.eclipse.edc.iam.identitytrust.sts.defaults.service.StsClientTokenGeneratorServiceImpl.tokenFor(StsClientTokenGeneratorServiceImpl.java:73)

......
some other useless stacktrace
......
       

What Goes Wrong

I understand that this is because there is another Vault in VaultPrivateKeyResolver which is also not properly set, and that changing the way to seed the vault may also solve this one. However, I believe having a NullPointerException is not desired even when I have the wrong config. So I dig a bit deeper.

After debugging I found the root cause comes from line 71 in StsDefaultServiceExtension:

(client) -> privateKeyResolver.resolvePrivateKey(client.getPrivateKeyAlias()).orElse(null),

In a word, the parameter failureAction in orElse should not be null, as you would later have failureAction.apply(xxx).

Quick Fix

A slight change in line 71 works:

(client) -> privateKeyResolver.resolvePrivateKey(client.getPrivateKeyAlias()).orElse( (failure_action)->null ),

[harnvo]

I later tried manually adding vault.storeSecret("secretAlias", "clientSecret"); during initialization of StsClientServiceImpl, but running the example gives me the following output:

DEBUG 2024-06-20T22:31:00.840818906 Resolving secret secretAlias
DEBUG 2024-06-20T22:31:00.844244755 Resolving secret 1
DEBUG 2024-06-20T22:31:00.845082662 [PrivateKeyResolution] Public key not found, fallback to config. Error: Private key with ID '1' not found in Vault
SEVERE 2024-06-20T22:31:00.847577119 JerseyExtension: Unexpected exception caught
java.lang.NullPointerException: Cannot invoke "java.util.function.Function.apply(Object)" because "failureAction" is null
        at org.eclipse.edc.spi.result.AbstractResult.orElse(AbstractResult.java:105)
        at org.eclipse.edc.iam.identitytrust.sts.defaults.StsDefaultServicesExtension.lambda$clientTokenService$1(StsDefaultServicesExtension.java:71)
        at org.eclipse.edc.iam.identitytrust.sts.defaults.service.StsClientTokenGeneratorServiceImpl.lambda$tokenFor$0(StsClientTokenGeneratorServiceImpl.java:58)
        at org.eclipse.edc.token.JwtGenerationService.generate(JwtGenerationService.java:45)
        at org.eclipse.edc.iam.identitytrust.sts.embedded.EmbeddedSecureTokenService.lambda$createToken$1(EmbeddedSecureTokenService.java:74)
        at org.eclipse.edc.spi.result.AbstractResult.compose(AbstractResult.java:185)
        at org.eclipse.edc.iam.identitytrust.sts.embedded.EmbeddedSecureTokenService.createToken(EmbeddedSecureTokenService.java:72)
        at org.eclipse.edc.iam.identitytrust.sts.defaults.service.StsClientTokenGeneratorServiceImpl.tokenFor(StsClientTokenGeneratorServiceImpl.java:73)

......
some other useless stacktrace
......
       

What Goes Wrong

I understand that this is because there is another Vault in VaultPrivateKeyResolver which is also not properly set, and that changing the way to seed the vault may also solve this one. However, I believe having a NullPointerException is not desired even when I have the wrong config. So I dig a bit deeper.

After debugging I found the root cause comes from line 71 in StsDefaultServiceExtension:

(client) -> privateKeyResolver.resolvePrivateKey(client.getPrivateKeyAlias()).orElse(null),

In a word, the parameter failureAction in orElse should not be null, as you would later have failureAction.apply(xxx).

Quick Fix

A slight change in line 71 works:

(client) -> privateKeyResolver.resolvePrivateKey(client.getPrivateKeyAlias()).orElse( (failure_action)->null ),

Hi @wolf4ood

Thanks your for swift fix of this issue. I wonder if it is still necessary to have this slight modification to prevent potential NullPointerException.