Multitenancy Extension

[aaronanderson]

Description

A prototype is available here: quarkus-multitenancy

Quarkus already has some multitenancy support via the OIDC extension. This extension provides high level multitenancy support that other Quarkus extensions or web-based applications can utilize to tailor individual application tenant security and settings.

Key features:

Tenant Resolution - Identification based on subdomain, i.e. (tenant1.acme.com) or base path, i.e. (acme.com/tenant1). Tenant Routing - Optional automatic Vert.x internal rerouting of requests from tenant paths to root paths, ie. /tenant1/ -> / or /tenant1/graphql -> /graphql Tenant Configuration Loading - lazy load application specific tenant settings that are cached and then made available on every request as Vert.x RoutingContext data. Custom CDI Tenant Scope - Inject tenant configuration properties per request Quarkus OIDC TenantConfigResolver Compatability - Support per tenant OIDC configurations.

Repository name

quarkus-multitenancy

Short description

Web application Multitenancy support with tenant resolution and tenant CDI scope

Repository Homepage URL

https://github.com/aaronanderson/quarkus-multitenancy

Repository Topics

• quarkus-extension
• multitenancy
• custom CDI scope ...

Team Members

• @aaronanderson

GitHub Applications?

• [ ] Stale - Automatically close stale Issues and Pull Requests that tend to accumulate during a project

Additional context

No response

[sberyozkin]

Interesting. @FroMage Hi Steph, can it be of interest to Renarde as well ?

[GavinRay97]

I'd have a use case for this

[rquinio1A]

Also related to https://github.com/eclipse/microprofile-config/issues/729

[gavinking]

Somewhat related https://github.com/quarkusio/quarkus/issues/11861

[sberyozkin]

Hey @gastaldi, are you OK with having this possible Quarkiverse extension enabled ?

[gastaldi]

@sberyozkin that looks really cool, I wonder if it shouldn't be a core feature or be a core extension, given that it can be useful to other extensions. WDYT @gsmet ?

[GavinRay97]

Just wanted to check back in on this

I think multi-tenancy ought to be a core, optional feature of Quarkus tbh. It's a critical feature for some applications, who have their entire domain & design based around it (my org's app is one case).

The author's code has some testing stuff in it (like a demo homepage etc) If the Quarkus folks are okay with, and if the author is too busy, I could also try to continue work on this?

This touches a lot of stuff I haven't contributed to before, like core arc.Context though.

[aaronanderson]

I am willing to contribute further in any capacity if desired.

I concur that it would be beneficial if multitenancy be a core feature for security and extensibility purposes. Other extensions could add multitenancy support using a unified framework instead of individual patchwork approaches.

Perhaps there could a build time flag like quarkus.multitenancy and if the value was false then all multitenancy functionality would be removed at build time. The minimum core functionality would be a tenant resolver ( X-TENANT-ID, path, or subdomain), some kind of TenantConfigSource (like the MicroProfile ConfigSource), and a security check to prevent cross tenant access.

The tenant custom CDI scope is nice syntactic sugar but it wouldn't necessarily need to be a core feature. There could be other alternatives like a @Tenant qualifier annotation on a @RequestScope or @ConfigProperty injection or even a utility method to retrieve the tenant information from the Vert.X RoutingContext where the tenant resolution actually occurs.