search

brockallen / BrockAllen.MembershipReboot

MembershipReboot is a user identity management and authentication library.
Other
742 stars 238 forks source link

Feature Request: Support multi-tenant relationships outside of the useraccount table #615

Closed markchipman closed 8 years ago

markchipman commented 8 years ago

Currently, multi-tenant support exist in MR, however the structure is rigid for defining tenants... I'd like to see the support of multi-tenancy slightly differently, however it would entail a bit of refactoring of MR.

Proposed table structure(s):

TENANTS (new table) TenantId (PK) TenantName .... OtherRelatedTenantDetail

USERACCOUNTS (existing table) Key ID UserName .... OtherRelatedUserDetail

TENANTSUSERACCOUNTS (new many-to-many relational table) TenantsUserAccountsID (PK) TenantID (FK - tenants) ID (FK - useraccounts) .... OtherRelatedTenantUserDetails (ie: possibly hashed password, email, etc if refactored to here)

As you can see, this structure is much more versatile and flexible. Brock, any chance of you tackling this variation as an additional sample/example? I hope to have the ability to benefit from this via IdentityServer using ACR:tenant data being submitted upon login (as shown in the existing samples).

Note: all of the other cursory tables such as UserClaims, UserCertificates, TwoFactorAuthTokens, etc. would then need to be related to the PK in the TENANTSUSERACCOUNTS table instead of to the [Key] in the USERACCOUNTS table.

Would this be valuable to anyone else?

Mark

markchipman commented 8 years ago

On second thought, I can now see that in doing such a things I'm just moving concerns from one table to another. I can simply adopt the existing MR structure into my desired schema and get to where I need to be. :)