Support many to many tenant - user relationship

[AndrewTriesToCode]

Most of the strategies and examples thus far assume that each tenant has its self-contained set of users. However, there are good use cases for a many-many relationship between users and tenants.

Goals:

• allow a user to belong to multiple tenants
• allow some mechanism for them to "navigate" between tenants.

Implications:

• if a user navigates to a certain tenant then we need to know where to send them (ie url) thus there will need to be a way to figure this out given the strategy used
• a separate auth cookie per tenant might not work -- might need to support a single cookie with multiple identities/claims per tenant for the user -- this would require authentication to occur before multitenant middleware, but some things like challenges would still need to occur after the middleware

[markgould]

We have a need for this - our admin users at our company have access to our customer tenants. I've setup a default tenant that we belong to.

If a user is in an "Admin" role, I display a dropdown on the page that lists the different tenant. When they select one, it simply sets a TenantId session parameter. In my Tenant Strategy, I check if this session value is set, and use that, otherwise I use the default strategy (in this case it resolves based on the domain of the user)

I'd be interested in seeing how you support this.

[AndrewTriesToCode]

hi @markgould

Thanks for the email--I'll get back to you shortly on that.

For this item the approach you describe above is similar to my thinking. Either a session variable or something in the auth cookie like "effective tenant" or similar. I'm heads down getting a release for .NET Core 3 but will pivot back to this afterward.

[pracsol]

I would like to see some sort of support for this. I'm using Azure B2C to hold users who each have an extension attribute for their tenant identifier. Since the user email address must be unique, I need a way to bind the user to multiple tenants. I've thought about a few ways of doing this, with one idea being to treat the tenant identifier as a list (e.g. delimited string) and if multiple values exist when user first comes into app, they choose the tenant if more than one exists. Interested in any patterns people have found success with on this front.

[pracsol]

@AndrewTriesToCode does this issue still have any mindshare or traction? I mean, I guess it was dropped as a milestone years ago, but still open - is that because there's an effective implementation pattern to address the issue currently as-is? Thank you

[AndrewTriesToCode]

hi @pracsol

It's still a common use case but I think a blog post or documentation of an example approach would be the best because each use case I see is slightly different. I just don't have a ton of time. The main thing about this is NOT to use the MultiTenantIdentityDbContext support and instead fully model the many-to-many relationship in the regular IdentityDbContext... which is not clear from the documentation I have currently or to those who don't have strong modeling experience.

[pracsol]

Thanks @AndrewTriesToCode.

In my scenario we're really just after one-to-many (users account to tenants). We're not using EF, just Dapper, a claims strategy and a custom IMultiTenantStore<TTenantInfo> approach to storage - basically a databroker for tenant data. The TenantInfo class def contains the connection string and such for the tenant.

Have been thinking about doing something along the lines of what was discussed above: associating the user account with some special "base" tenant and putting such users through a sub-tenant selection process at login, and then populating a set of "ActiveSubTenant" fields in the TenantInfo object. Seems like it might work if the app always treated this subtenant data as the authoritative, and sent them back to the selection workflow if the account is a member of the base tenant and had empty subtenant fields. The interface could probably allow some flavor of subtenant logout that just clears the fields, so they get sent back to selection workflow without logging the account out.

I'd be grateful for any insight into what you've seen others do in that circumstance, or if there's a more elegant "known good" pattern these days for this situation.

Thanks Again!

[AndrewTriesToCode]

hi @pracsol how has this worked out for you?