-
Notifications
You must be signed in to change notification settings - Fork 2.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate OIDC-based extensions from config classes to @ConfigMapping
#39185
Comments
/cc @pedroigor (oidc), @sberyozkin (oidc) |
+1 |
@michalvavrik FYI,
IMHO it has to be reviewed. I'm quite sure I saw people asking questions about accessing the OIDC config, probably a long while back on Zulip, but I remember it. FYI, Keycloak Authorization and now OIDC Proxy need access to OidcTenantConfig but the latter accesses it via an instance of |
Thanks for quick response @sberyozkin .
First I tried to detect whether the migration is acceptable. I'll try it, I expect it to work and if it does not, IMO it is candidate for new feature that I'd request from SR Config.
Just because someone asked in past, it doesn't mean that person is still using it. I'm happy to investigate Quarkiverse extensions usage if you suggest concerned extensions (or I can try to look at Mvn central usage of the OIDC extension if it is there and inspect dependencies that are using the OIDC). That's only thing I can investigate.
Hey, but OIDC Proxy extension is not released and Keycloak Authorization is in core, which I can fix as I'll migrate it. I agree that everything has to work as before, just migration from properties/getters to interface methods if that's what you mean by this FYI. |
@michalvavrik One more thing I remember. Dynamic |
I can see it is documented and used, alright, we can keep the Would it be acceptable @sberyozkin to keep |
OIDC config probably covers may be 10+ different aspects, TLS, Proxy, OIDC connections details, a ton of them. And recall, this is created per tenant, dynamically. I think if we can come up with a good |
Though I'm not sure it is worth the effort, only if we will want to break the current approach. But |
Alright then, I'll (eventually, not right now):
Then based on concrete proposal there can be discussion whether it's acceptable or not. |
@michalvavrik Sure, but lets avoid breaking |
Roger That. |
ouch, I punched enter before I finished - it is interesting because there is overall intention to unify Quarkus specific config and SmallRye Config. So I meant to say I'll that OIDC extension migration will be bigger effort that I'm working on, but I'll start slowly with tiny PRs like OIDC token propagation that I already checked has no usage in Quarkiverse. And so on. thx |
I made a smoke check in regards of the OIDC and the OIDC client extensions.
My understand is that we can keep consistency reliably because the POJOs will implement the Even so, I think it is likely that users are injecting |
Just adding link to the current proposal #41866 (comment). Starting to working on the phase one right now. I think it's the right way to go, but I won't really know till I try it. I also need to look into extensibility of Update: found one test in IT SR Config module that extends |
Description
I've mentioned extensions migrating to
@ConfigMapping
along its own axis. Some of them try to solve a bug like Hibernate, but there are other objections like performance, efficiency and possibly new features (config classes are maintained if there is a major bug found, but not developed). Cons is that some config classes can be injected by integrating extensions or users, therefore they can be considered API - #35246. However I don't believe that is a case of OIDC, how many extensions and users outside of Quarkus core extensions really needs to inject configuration classes as CDI beans, or use them in a build step?I'd like to migrate OIDC config because I think impact will be absolutely minor. I don't know why should users inject OIDC config in general. Waiting probably solves nothing and migration can have positive performance impact (though migrating OIDC alone will hardly be measurable, it is one piece of the puzzle...).
Implementation ideas
No response
The text was updated successfully, but these errors were encountered: