quarkus-oidc adapter has to support KeycloakConfigResolver alternative available in VertxOAuth2

[sberyozkin]

@pedroigor FYI

[sberyozkin]

A comment from a user:

Description
I've implemented the KeycloakConfigResolver due to the fact that our backend service must deal with multiple tenants. In that situation, why must i specify a keycloak.json file (or properties) inside resources folder? I know that can be useful as a "default fallback", but in some cases we just don't want something like this. Imagine a sidecar service which intercepts calls before forwarding to the underlying microservice. In this case we'll have:

    Several tenants configuration
    Clients in configurations could be different from one another
    files named as the realm name (we intercept the JWT and resolve the config path extracting the realm name from the iss field)

[sberyozkin]

See this Vertx issue.

[sberyozkin]

Hi Pedro @pedroigor I'll be happy to work with you on this one in the next week or so. If you'll have time then I'll be helping alongside, otherwise I can probably fix it.

The question I have is, now that we have a realm value appended to the IDP URL, do we need to parameterize that value ? Or, with the multi tenant deployments, it is still the same realm, only different client properties within that realm ?

[sberyozkin]

@pedroigor I reckon now it does not really matter, whether it is realm specific or not, we'll likely need to use the configuration profiles anyway.

[pedroigor]

@sberyozkin We should also be able to allow configuration to be chosen based on incoming requests (dynamically). For instance, depending on a path you may want to use Tenant A, etc ..