Skip to content
This repository has been archived by the owner on May 1, 2019. It is now read-only.

Missing SignInManager #17

Open
igotlotsofspace opened this issue Aug 18, 2015 · 4 comments
Open

Missing SignInManager #17

igotlotsofspace opened this issue Aug 18, 2015 · 4 comments

Comments

@igotlotsofspace
Copy link

Hi James,

Thank you for putting in the effort to make this code publicly available. (I do not understand why Microsoft would spearhead SaaS in the industry and promote multi-tenant solutions using Azure, yet release an identity system that lacks multi-tenanting support.)

I've studied your samples and had success with a few simple trial runs. However the confusion begins when attempting to implement your solution in a real-world example. Granted, I am sure that it could very well be a lack of understanding on my part. Nevertheless, here are some direct examples I would like to share with you in an effort to gain insight on your recommended solution. I am sure many would benefit from it as well.

If you were to create a brand new MVC5 project right out of the box using Visual Studio 2013, followed by adding your solution via NuGet, you would get a similar project found in your examples. However, there appears to be many key elements missing and am thoroughly confused on how to recover them.

For example:
The file /App_Start/IdentityConfig.cs is missing, which in turn directly affects all the controller actions that deal with ApplicationSignInManager and ApplicationUserManager found in the AccountController and ManageController.

I understand that your solution resolves the ApplicationUserManager, but what about the SignInManager and all of the features that it provides? It seems that if users were to implement your solution, they would be giving up the ability to perform the following:

  • Create New Users
  • Use PasswordSIgnInAsync and get a result to which can determine a lockout or added verification
  • Changing Passwords
  • Sending a Code via SMS
  • Verifying Phone Number
  • TwoFactorAuthentication (enable and disable)

Lastly, I've read your other replies and would like to assure you that I understand the primary purpose of the project was to provide multiple usernames per tenant; and that all other coding is up to the developer. But please consider that your solution addresses only part of the entire identity spectrum, and that even the standard vanilla template produced by Visual Studio leaves so many questions unanswered. Please help developers like myself understand how to use your fantastic solution, while keeping the other necessary functions.

Again, thank you for your help.

JM

@jpsullivan
Copy link

Currently dealing with the same issues on my end. I think James has the right idea with most of this, but there are indeed many areas that should be addressed using the new vanilla template.

I'll keep trying to solve this on my end and will update here if I have any luck.

@igotlotsofspace
Copy link
Author

I ended up abandoning this approach. The standard identity model allows you to append custom columns to the Users Identify table and therefore I created a TenantID column with a relationship pointing back to a Tenants table. I am able to isolate my tenants throughout the program and do all my CRUD operations properly without the need of 3rd party tools. The one claimed advantage of this multi-tenant extension was the ability to have unique usernames per tenant. Yet I ended up going based on email address anyways, which in conjunction with the tenant id approach mentioned above, addresses everything I need. Good luck.

@jpsullivan
Copy link

Ironically enough I managed to get this implemented correctly just yesterday.

I ended up also abandoning the aforementioned approach as well, and wrote an OWIN middleware to handle tenant detection on a per-request level. Heavily influenced from SaasKit.

Ultimately, I'm still not 100% sold on the implementation, but it works and I get to have everything I initially wanted -- I just wish it was a bit more straightforward.

@markchipman
Copy link

markchipman commented Jul 6, 2016

I've read all of the above comments and I think the secret sauce lies in using a combination of the following to address most multi-tenant needs...

  1. Use JSkimmings MT framework from here... This takes care of the user-tenant mappings...
  2. Use zzzprojects/EntityFramework-Plus framework (https://github.com/zzzprojects/EntityFramework-Plus) as well... review the query filter capabilities as well as the auditing function as a bonus! Good stuff.
  3. Watch "ASP.NET in Multi-tenant App, Examples in MVC, ExtJS, and Angular"
    by Peter Kellner on PluralSight... get his sample codebase and benefit from the great ability to detect tenant via url, as well as add some slick Redis caching to have rippin fast queries (with on the fly SQL query if not in cache).
  4. Use IdentityManager (User & Identity Management) by Brock Allen https://github.com/IdentityManager/IdentityManager to handle assigning roles and claims to users. This might be best used in a sub-domain fashion (ie idm.mywebsite.com) to keep things cleanly segregated.
  5. Create any custom authorization attributes for your controllers that you need, in order to limit access only certain people within a specified tenant and throw on any other custom permissioning capabilities that you might also desire.
  6. Last but now least, add "ASP.NET Identity 2.0: Implementing Group-Based Permissions Management" role-grouping capabilities (groups are composed of one or more roles... and assigned to one or more users). See: http://johnatten.com/2014/08/10/asp-net-identity-2-0-implementing-group-based-permissions-management/.

I hope everyone can benefit for the synergy of all this these to create super flexible multi-tenant websites. BTW, I'm able to re-purpose the tenantID to be a "multitenantID" and then use the things I learned from Peter's video to determine the account, tenant and website IDs (per HTTP request) so that now I can determine via a simple setting in my web.config if the multitenantID represents the broad "account" ID, or the narrower scoped "tenant" ID or lastly the finely scoped "Website" ID. Thus it's easy to segregate many tenants or websites to use the same login credentials. This helps when you want three or four related websites to all use the same logins (and when you modify one, they are in essence having it apply to all of the websites).

Good luck everyone.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants