Identity: Support Multi Tenancy out of the box

[mbeckenbach]

Lots of guys out there build multi tenant apps. This is a feature, that should be part of a modern identity framework.

Maybe the mechanism could be similar to roles. A user can be a member of one or more tenants.

This would allow to easily set permissions, change the frontend theme or control data access by tenant.

I'm thinking on a quite easy way to access this info like

if(User.IsInTenant('microsoft')) {
// do some thing tenant specific
}

or

User.GetTenants();

Also this could be coupled with azure ad multi tenant apps in a nice way.

[blowdart]

Multi-tenancy is not a goal for identity. We expect Identity to be used as a starting point for simple identity scenarios.

As everyone's requirements around multi-tenancy differs based on their application architecture doing something generic would probably end up too limiting to be useful.

[brockallen]

And as a suggestion for the OP -- you could simply create an abstraction around Identity (like a factory which accepted the tenant as a param) which would create/initialize the correct tenant of the identity system.

[papyr]

This should be revisited!

Just because your view is that its too broad, should not limit the fact that its an important feature.

• Web apps are broad in general in general but this is a core feature and not for the easy!

[brockallen]

I just implemented this recently, and it was not that difficult. It did require a good understanding of the inner workings of the framework. I agree it should be better integrated/supported by the ASP.NET Identity framework itself, though.

[luisgizirian]

Any chance you can share your efforts Brock?

On Thu, Jan 12, 2017 at 10:59 PM Brock Allen [e-mail]
wrote:

I just implemented this recently, and it was not that difficult. It did
require a good understanding of the inner working of the framework. I agree
it should be better integrated/supported by the ASP.NET Identity
framework itself, though.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Identity/issues/266#issuecomment-272340815,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkinRpHDUm_CZHs-KYiE921pgPaIoXRks5rRtqLgaJpZM4C_erG
.

[brockallen]

iirc, here's the short list of what i did: delete the 2 username and email indexes the built-in stuff creates. add a tenant column to the user table. add new indexes for username/tenant and email/tenant. add a tenant to the store and change the IQueryable users property to filter on tenant.

[brockallen]

also, in the store overload create and set the tenant on the user.

[brockallen]

the most painful part of all of this is the base DbContext creating the 2 indexes on username and email and EF not providing an easy way for a derived DbContext to undo base class OnModelCreating stuff. better support would be in EF to delete an index on the ModelBuilder, or in ASP.NET Identity to have virtuals for pieces of this so you can override some of them rather than having to replace all of OnModelCreating and copy 95% of their default code. // @HaoK @rowanmiller

[luisgizirian]

Thanks! We have an Identity v2 customized for Multitenancy based on a
GitHub Jskimmer library. As we couldn't understand how to make it work on
v3 we have a bigger migration on hold. We'll investigate on your guidance.
On Thu, Jan 12, 2017 at 11:03 PM Brock Allen [e-mail]
wrote:

iirc, here's the short list of what i did: delete the 2 username and email
indexes the built-in stuff creates. add a tenant column to the user table.
add new indexes for username/tenant and email/tenant. add a tenant to the
store and change the IQueryable users property to filter on tenant.

—
You are receiving this because you commented.

Reply to this email directly, view it on GitHub
https://github.com/aspnet/Identity/issues/266#issuecomment-272341418,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkinRNH2h7AjOWSF5R4dGoM8vtrQq4Bks5rRtt_gaJpZM4C_erG
.

[brockallen]

feel free to fund me working on an OSS version of it for AspId3 :)

[luisgizirian]

Sure thing!
On Thu, Jan 12, 2017 at 11:10 PM Brock Allen [e-mail]
wrote:

feel free to fund me working on an OSS version of it for AspId3 :)

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/aspnet/Identity/issues/266#issuecomment-272342365,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAkinWtIW13UJgdY35j9YMg_8wVjhrnEks5rRt0PgaJpZM4C_erG
.

[tugberkugurlu]

Putting each tenant's identity data into a different database would accomplish that unless I am missing something. That way you can pretty much use all of the identity implementations out there within your multi tenant app.

To my experience, it's mostly a good idea to keep the database(s) single tenant whereas you keep the application level multi-tenant. This surely increases the operational costs (e.g. monitor more databases, backups of all, updating more databases (if your database has schema), running migrations on more databases (no matter if your database is schemaless or not), etc.). However, the benefits are really worth the effort. For example, this approach would allow you to allocate different level of resources for your each tenant. In identity case here, each tenant can have customized database resources (e.g. Tenant A's identity database is on a SQL Azure Premium database since it has 10 million users, Tenant B's identity database is on a SQL Azure Basic database since it has 1000 users, etc.).

What we lack the most on this around .NET space is not the tooling/library support, but the docs.

[luisgizirian]

We're using AspNet Identity v.2 with Mutitenancy support using @jskimming library (https://github.com/JSkimming/AspNet.Identity.EntityFramework.Multitenant).

Following on @tugberkugurlu comments, on the DB side of our evolution plan, we'd like to use an Azure Elastic Pool for SQL. Here, the sharding key would be the TenantId.

Without Identity's v3 supporting multitenancy the way we do with v2, we can't find a way to move to v3, so it forces us to keep doing v2 on MVC5.

To clarify what I said earlier on this thread, this is also stopping us from a bigger move on porting all our platform to AspNet Core and being able to run our workloads into Azure Service Fabric.

[tugberkugurlu]

we'd like to use an Azure Elastic Pool for SQL. Here, the sharding key would be the TenantId.

@luisgizirian AFAIK, you can put multiple databases into the pool with Azure Elastic Pool, no? I thought that's the whole idea of it. Otherwise, what would be the diff of it from sharding?

[luisgizirian]

Sorry @tugberkugurlu, can't see your point (feel free to write me directly). Lets please not deviate the discussion from the main issue here. :)

[JSkimming]

@luisgizirian I've been somewhat neglecting that library I created, I don't have the time and I don't use it myself (the project for which it was written never took off).

I'd happily review any pull requests should someone submit one, also happy to consider freelance work 😃

[weedkiller]

https://github.com/aspnet/Identity/issues/569

So many others here have this need! any chance on updating this at @JSkimming or @tugberkugurlu lib

[tugberkugurlu]

@luisgizirian I don't mean to deviate from the issue. I am talking about something related which you originally brought up.

The point I am trying to make is that storing the identity data in one database for all of your tenants is a not a good idea at all. There are so many things that can go wrong if you architecture your system in this way. See https://ayende.com/blog/3497/multi-tenancy-the-physical-data-model for a few of those scenarios.

Even if you are OK with this architecture, a generic library like ASP.NET Identity should not encourage you to adopt this pattern. In fact, clearly, it's not hard to do this w/o having an explicit support from this library if you really want to shoot yourself in the foot.