-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Allow to set OIDC tenant using annotations #22974
Comments
/cc @pedroigor, @sberyozkin |
@j-be I think your approach is the simplest; with |
@sberyozkin Sounds good to me. If you point me to how and where I can do the documentation update - I'm more than happy to provide a rough draft. Same goes for |
@j-be Sorry, I mistyped, it is an internal DefaultTenantConfigResolver. I believe
can be optimized/replaced with
Looks like the If you can create a PR then it would be appreciated |
Sure thing, always happy to help 😃 |
@j-be Thanks |
refs quarkusio#22974 Signed-off-by: Juri Berlanda <[email protected]>
Related #34692 |
Description
Lets assume one has a big API in a single Quarkus service (i.e.
quarkus.oidc.application-type=service
), but different APIs are for a different group of people. Like: this JAX-RS annotated class provides endpoints solely for HR, this other class solely for finances, this class is solely for engineering, and so on.Now, usually one would solve that using roles, but a problem arises when those groups of people are authenticated by different OIDC providers.
We can still leverage OIDC multi-tenancy to solve the issue, but
TenantResolver.resolve(RoutingContext)
offers very little information (apart from the raw request path/URL) to base the decision on.In such scenarios it would be really nice to be able to specify the tenant using annotations, like:
Implementation ideas
As proposed by @mkouba on Zulip one could leverage an
@Interceptor
to manipulateRoutingContext
and use that inTenantResolver
, like:As @sberyozkin pointed out: by patching
DefaultTenantResolver
to check for the value we should even be able to avoid a dedictatedTenantResolver
.With a bit more effort it should also be able to implement a parameterized version of the annotation, like:
The code providing support for
@CacheInvalidateAll
with itscacheName
parameter should be exactly the same as we'd need here. But I think that is not worth posting here.The text was updated successfully, but these errors were encountered: