You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It should be possible to dynamically (after application is started) add tenants, for each tenant you should have it's own auth identity providers (form login can be enabled or not per tenant, and of course users should be in different data sources, each tenant would have it's own login page (some with username and password, some only with OIDC, some with SAML2, etc, each login form having it's own url containing the tenant), multiple oauth2 clients (different configuration for each tenant, and possibility to add / remove / change client configuration for each client at runtime not startup which is not possible right now), saml (add/remove/change saml settings at runtime for each tenant). Also even the SecurityFilterChain are hard or impossible to configure per tenant, since tenants should be dynamic, meaning being able to add a new tenant with it's own OIDC, SAML, form login requirements, at runtime.
Current Behavior
Now it is not possible to create a Spring Security application that supports multiple dynamic tenants (each of them having different login options like form enabled or not, their own oauth2 client configurations - like login with Google, etc, their own SAML configurations, etc). All this things are static and should be known at application start, which is not possible in a case where you want to be able to add tenants dynamically and configure their auth.
Context
A lot of people struggle to deal with multi tenancy using Spring Security (and Spring Authorization Server, Spring Cloud Gateway, Spring OAUTH2 Client).
Trying to create a multi tenant application secured by Spring Security, tenants can be added dynamically (at runtime) and each client has its own security "requirements" that might need adding extra SecurityFilterChain, adding extra login page (with new tenant in url), extra configs for OAUTH2 clients - the new tenant that is added at runtime might need Google login, but with a different Google client and secret), new SAML settings, etc).
Now there are a lot of issues that cannot be solved if you want to use Spring Security (and Spring Authorization Server, Spring Cloud Gateway, Spring OAUTH2 Client).
The text was updated successfully, but these errors were encountered:
@sebutzu thank you for reaching out and bringing up such an important topic!
However, looking through this issue, what you mention is conceptual and high-level and there is nothing specific or actionable for us to do in Spring Security. Further, multi-tenancy is a large and cross-cutting feature that is much bigger than just the security framework. For example, adding and removing beans at runtime and re-configuring Spring applications on the fly is not the domain of Spring Security.
Having said that, I hear your struggle and agree that this topic is important and it would be nice to have richer and easier support for building multi-tenant applications with Spring Security. Please know that it is something we are discussing, and seeing issues like this helps us understand the priority the community places on this topic. I will take this feedback to the team.
There are already several issues in the backlog discussing multi-tenancy and this issue is very conceptual and high-level. For that reason, I'm going to close this issue. This issue does not address anything specific and therefore is not actionable. I would encourage you to search this project for issues that address more specific things you're thinking about and consider adding comments to explain your use case in detail. If you don't see any other issues that are related, please consider opening more specific issues that target specific aspects of the framework and are actionable so that we can work to gradually enhance multi-tenancy support. Please let me know if you have any questions about this.
Expected Behavior
It should be possible to dynamically (after application is started) add tenants, for each tenant you should have it's own auth identity providers (form login can be enabled or not per tenant, and of course users should be in different data sources, each tenant would have it's own login page (some with username and password, some only with OIDC, some with SAML2, etc, each login form having it's own url containing the tenant), multiple oauth2 clients (different configuration for each tenant, and possibility to add / remove / change client configuration for each client at runtime not startup which is not possible right now), saml (add/remove/change saml settings at runtime for each tenant). Also even the SecurityFilterChain are hard or impossible to configure per tenant, since tenants should be dynamic, meaning being able to add a new tenant with it's own OIDC, SAML, form login requirements, at runtime.
Current Behavior
Now it is not possible to create a Spring Security application that supports multiple dynamic tenants (each of them having different login options like form enabled or not, their own oauth2 client configurations - like login with Google, etc, their own SAML configurations, etc). All this things are static and should be known at application start, which is not possible in a case where you want to be able to add tenants dynamically and configure their auth.
Context
A lot of people struggle to deal with multi tenancy using Spring Security (and Spring Authorization Server, Spring Cloud Gateway, Spring OAUTH2 Client).
Trying to create a multi tenant application secured by Spring Security, tenants can be added dynamically (at runtime) and each client has its own security "requirements" that might need adding extra SecurityFilterChain, adding extra login page (with new tenant in url), extra configs for OAUTH2 clients - the new tenant that is added at runtime might need Google login, but with a different Google client and secret), new SAML settings, etc).
Now there are a lot of issues that cannot be solved if you want to use Spring Security (and Spring Authorization Server, Spring Cloud Gateway, Spring OAUTH2 Client).
The text was updated successfully, but these errors were encountered: