-
Notifications
You must be signed in to change notification settings - Fork 4k
Official implementation of multitenancy #2673
Comments
there's nothing in IdentityServer that prevents it. but the problem is that your definition of it is possibly different than many others. much like the whole authentication system, this would be something you would need to implement according to your semantics. |
The multitenancy definition I have in mind for my project is world standard, considering the approach of having only one database, separating the records of each tenancy by the tenantId. If I do not have anything to add I will close the issue. |
which records? user records? clients? apis? also, how do you want to present the tenant identifier? acr_values, host name, something else? i don't think there's a "world standard" and that's why i said multi-tenancy is different for different people, therefore there are different strategies based on what the real requirements are. |
Lets go... In front of this use case, my question is whether the identity server has some native implementation, and if you do not have it, if it is legal to implement all this control within the identity server, even if this approach is not cool, have some idea at the architecture level of how to implement this control with regard to authentication and authorization, since in multitenancy model, considering the approach I suggested, I need to have in a same database of my identity server, isolated records by tenantId. In direct answer to your questions: which records? user records? customers? apis All records required for isolation: As users, roles, claims, and so on. do you want to display the tenant identifier? acr_values, hostname, anything? host There is a worldwide standard and a person who is multi-tenancy is different for different people Sorry, I expressed myself very poorly citing a world standard. |
All of what you are asking for is possible. But some coding must be done on your part to implement these semantics. It's not a built-in feature, though. |
OK understood! Thank you |
I'm really struggling with this problem too at the moment. In my case I need IdentityServer to authenticate multiple clients (web applications) like this: A user goes to http://webserver/app1 and gets redirected to https://identityserver for authentication. Then he opens another tab and goes to http://webserver/app2 expecting to get redirected for authentication again (it's ok if authentication for app1 is lost at that point). What really happens is different - he is already signed in to https://identityserver so gets back to app2 with a wrong identity. @brockallen here you mentioned:
But IdentityServerAuthenticationService (in 2.2.0) has this piece of code which rules out multiple identities:
The other option is to use multiple cookies but, again,
So my question is if I need IdentityServer to be multitenant do I have to replace the whole cookie authentication layer?
|
@brockallen, I am trying to get to the answer from long but not getting anything complete in any discussion thread. |
Update: my initial plan with http://webserver/app1 and http://webserver/app2 didn't work because of the nonce cookie which is issued for the domain. That's a wrong path. The proper approach is to use separate subdomains for each application like this: http://app1.webserver, http://app2.webserver. Now each domain has it's own cookies and everything works fine. @asharda1 the client already passes the clientId claim so it's possible to implement multi-tenancy by using just that. It requires a helper table mapping clients to tenants though. |
@nikoudel It is possible to prepare an example |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Describe the solution you'd like
Definitely and directly, does identity server 4 support multi tenancy?
Could you forward the documentation link with a get starter where you implement this feature?
Thank you!
The text was updated successfully, but these errors were encountered: