How to correctly use env properties with named OIDC clients

[sberyozkin]

@jorgebsa had issues with configuring the named OIDC client in #40469, so I'm opening a more focused discussion here. @jorgebsa commented at #40469:

My initial attempt was to add the following environment variables to the helm template: QUARKUS_OIDC_CLIENT__ABC_CLIENT__PROXY_PORT and QUARKUS_OIDC_CLIENT__ABC_CLIENT__PROXY_PORT. Once deployed, application kept failing to start claiming that the OIDC server was unavailable, as the request wasn't proxied.

My second attempt was to keep those properties and add to the prod profile on application.yml the following properties with empty values: quarkus.oidc-client."abc-client".proxy.host, quarkus.oidc-client."abc-client".proxy.port. It still kept failing.

So, here it is not a default client but a named one is used, for example, instead of quarkus.oidc-client.proxy.host=a.b.c, it is quarkus.oidc-client."abc-client".proxy.host=a.b.c.

Roberto, @radcortez, what I thought you explained awhile back, was that one had to declare an empty property like quarkus.oidc-client.proxy.host= before using an env property like QUARKUS_OIDC_CLIENT_PROXY_HOST due to the presence of - in quarkus.oidc-client.

What about a named OIDC client, should it be quarkus.oidc-client."abc-client".proxy.host= followed by providing a QUARKUS_OIDC_CLIENT__ABC_CLIENT__PROXY_HOST env property ?

I wonder, should it be a double underscore __ or just a single one: QUARKUS_OIDC_CLIENT_ABC_CLIENT_PROXY_HOST ?

Thanks

[jorgebsa]

Thanks for following up on this @sberyozkin . Just a note, on my original comment I had added a copy paste typo where I pasted twice the PORT env var, instead of the HOST. Just to be clear that it was one env var for each, I edited the original comment, but you had already started typing here, which explains why we see PORT twice as well hehe.

Let's hear what @radcortez has to say, let me know if I can provide more feedback guys, thanks for the support ;)

[radcortez]

Yes, correct, you need a QUARKUS_OIDC_CLIENT__ABC_CLIENT__PROXY_HOST with double __:
https://quarkus.io/guides/config-reference#environment-variables

[sberyozkin]

Thanks @radcortez, I tested quarkus oidc client quickstart, updated the default OIDC client to have an "api-client" name, updated src/main/java/org/acme/security/openid/connect/client/RestClientWithOidcClientFilter.java to have @OidcClientFilter("api-client"), and set the grant property to an empty value, quarkus.oidc-client.grant.type= and the test failed, then I exported export QUARKUS_OIDC_CLIENT__API_CLIENT__GRANT_TYPE=password and the test passed.

@jorgebsa You mentioned that

I went to the prod profile and mapped all oidc and oidc-client proxy properties to the env vars HTTP_PROXY_HOST and HTTP_PROXY_PORT, then went back to helm to remove all quarkus oidc and oidc-client proxy env var and added these 2 new envs. Deployed, and it all worked.

I'm not sure why you could not make it work with QUARKUS_OIDC_CLIENT__ABC_CLIENT__PROXY_HOST and QUARKUS_OIDC_CLIENT__ABC_CLIENT__PROXY_PORT, as long as you have the application.properties declaring the empty values it should work, please retest and debug when you get a chance.

If you'd like, try to reproduce a failure with the quarkus oidc client quickstart, in JVM mode

[jorgebsa]

@sberyozkin I haven't had time to come back to this, but I plan to do it this week still. But before that, maybe you or @radcortez could help me with this configuration topic, so that I could try to be more precise when attempting to fix it. Got a couple questions:

Assume that I have an application that will be distributed as a container image. This application is able to interact with any amount of third-party APIs, each of these APIs will require an OIDC client. However, the OIDC clients are only going to be defined at runtime by the client/devops/whomever is responsible for deploying it.

I, as the developer, am not aware of the names of the OIDC clients at all at build-time. Because of this, I can't prefill application properties with empty values for the possible oidc clients. In this case, it would be impossible to configure the application solely via environment variables, due to the limitation around the namespace and possibility of -, is this assumption correct?

Now assume that I were able to know the names, and for each oidc client around 4 or 5 properties need to be configured via env vars, do I need to prefill all of them with empty values, or would 1 be enough to have the rest mapped to the same named oidc-client?

[sberyozkin]

@jorgebsa Hi, I wonder if you should consider creating OIDC clients dynamically in such cases, there is example in https://quarkus.io/guides/security-openid-connect-client-reference#use-oidc-clients, showing how to create them on the fly... In these case you can use your own properties.

The example there shows using programmatically created OidcClient directly in the code, but you can use them in filters like this: #39262

[jorgebsa]

Hey, thanks for the suggestion @sberyozkin. In the scenario described above (it is a separate service, not the one that originated the discussion), I was so determined on trying to fix it via the config that I didn't consider the dynamic clients approach. Regarding this approach, I am caching the dynamic OidcClient and the accompanying TokensHelper instances in a map for now, as I don't expect these should be recreated on every usage, correct? Already tested, seems to work fine.

I will try to come back to the configuration problem of the other application later on, as it doesn't face the dynamic clients problem, on that one I can prefill the properties and override with env vars.

[sberyozkin]

@jorgebsa Indeed, these are thread safe objects