StsClientService + Identityhub + FsVault

[thomasrutger]

Hi, I want to run the SecureTokenServiceApiController with the IdentityHub and then use the connector with the RemoteSecureTokenService. This is so participants can be managed in one place. Since I am running in a local development environment I am using the FsVault.

I am running into the following problem:
Whenever I am adding new participants to the Identityhub, the private key is stored in the vault (when generating a new key on the spot). However, The StsClientTokenGeneratorServiceImpl uses the JksPrivateKeyResolver instead (which is loaded together with the FsVault). So the StsClientTokenGeneratorService` will not be able to find the private key. I tried instead to just preload the key in the keystore using the Keystore Explorer tool. However, I am getting the following issue:

java.lang.IllegalArgumentException: Could not convert PrivateKey to a JWSSigner, currently only the following types are supported: EC,RSA,EdDSA,Ed25519. The specified key was a ECDSA

So now I am a bit stuck, unless I resort to Hashicorp Vault, but I prefer to keep things simple in my local environment.

Any ideas on how to go about this?

[paullatzelsperger]

First off, the StsClientService doesn't use the JksPrivateKeyResolver, in fact it does not need to know anything about private keys.
The exception you saw seems like a small bug in the connector code.

What is the problem with letting IH generate and store the keys in the Vault?

Also, this discussion is better suited for the connector repo, will move.

[edit]: this PR should fix the IllegalArgumentException

[thomasrutger]

I made an error in my initial question, my apologies. I want to use the SecureTokenServiceApiController in the IH, which uses StsClientTokenGeneratorService. This gets the private key through a resolver, that is injected in StsDefaultServicesExtension. In my case, this is the JksPrivateKeyResolver, since I am using the FsVault.

What is the problem with letting IH generate and store the keys in the Vault?

The problem is that IH stores the key in the Vault, but the StsClientTokenGeneratorService looks for the key in the keystore, so it is unable to find the associated private key for a token request.

The exception you saw seems like a small bug in the connector code.

In that case, should this get fixed, I can still just add the private key material to the keystore in advance. But letting the IH generate a key on the fly is more convenient so if there is a way to use the FsVault, while using the VaultPrivateKeyResolver instead of the JksPrivateKeyResolver in the StsClientTokenGeneratorService, that would be great.

edit: I removed the FsVault dependency, and resorted to the default in memory vault, which does work in my scenario. This seems to suffice for now (I was unaware of the existence of the in memory vault).

[paullatzelsperger]

ah, now I got it. Here is the PR to fix the exception.

Yeah, unfortunately, once you use the FsVault, that'll also register the JksPrivateKeyResolver in the context replacing the VaultPrivateKeyResolver.

So for the time being my recommendation is this:

• in testing scenarios (read: unit/integration testing) use the InMemory Vault. You'll have to write some code to seed the secrets.
• for anything else use Hashicorp Vault. It's not that hard.

The FsVault will get removed in future versions of EDC, as it as serious limitations.

[thomasrutger]

Thanks for clearing that up and the recommendations!

[paullatzelsperger]

also, you could look at the MVD project, there we deploy HCV using Terraform.