Add HashiCorp Vault OpenId Connect and JWT authentication support

[sberyozkin]

Description See https://www.vaultproject.io/docs/auth/jwt

@vsevel Hi Vincent - what do you think ? adding the direct JWT authentication would be straightforward (the advantage - the secret does not go over the wire), but OIDC code flow is more interesting - this would effectively introduce a multi-tenancy into Quarkus Vault applications - a user logs in into Quarkus (via Vault IDP, maybe indirectly via Keycloak) and the data fetched from Vault would be specific to the current user, if I understand it correctly... quarkus-oidc can be used to support the OIDC authentication

Also CC @lordofthejars

[ghost]

/cc @vsevel

[vsevel]

hello @sberyozkin I do not know how much this use case is widespread, but your thinking makes perfect sense. the main challenge would be effectively maintaining a vult authentication associated to the current security context. right now everything is application scoped. so this would involve some rethinking in the vault extension. but I can see the value of it. in terms of priority, I would rather finish the refactoring that we started with https://github.com/quarkusio/quarkus/pull/13498, continuing with https://github.com/quarkusio/quarkus/pull/13537, and will finish with https://github.com/quarkusio/quarkus/pull/8885

[sberyozkin]

Hi @vsevel, I was thinking a bit more about it. The fact Vault is application scoped is not really a restriction for an enhancement like this one. You have an internal token authentication method implementation - currently the token is provisioned by the extension itself. I think that implementing an enhancement like this one would be simply about adding a light-weight quarkus-security dependency and injecting somewhere in this token authentication method implementation a Instance<TokenCredential> and use this token if it is available - this is all as far as I can see - we've done with @loicmathieu something similar for Google Cloud Services integration. TokenCredential injection is request scoped which would work fine if it has to be injected into an application scoped Vault token auth mechanism.

The rest will be taken care of by quarkus-oidc - it will be configured to connect to Vault OIDC and the user will authenticate into it and quarkus-oidc will acquire the token itself and make it available for the injection.

I guess this idea of making sure the user authentication is what scopes the Vault data available to Quarkus is not wide-spread is because, perhaps, it is considered a fairly advanced mechanism - but it would definitely add a new dimension to Quarkus Vault integration :-), and quarkus-oidc will just handle the whole OIDC specific interactions.

I suppose this feature, if it were to be done, would only apply to a case where the endpoints interact with the vault services directly, the early config source level data acquisition would not apply in this case - but may well complement it

Please think about it :-)

[sberyozkin]

@kdubb, Have you dealt with Vault OpenId Connect authentication ?

[kdubb]

@sberyozkin No, I've only been working on secret engines. Nothing with authentication.

[sberyozkin]

I might do a draft PR for @vsevel to consider