I am testing out Identity for my ASP NET CORE MVC application. From what I have read the Identity solution provided is probably the way to go now considering user management and security for logins.
What I have not yet understood is if it is somehow possible to combine the Identity solution with custom groups?
Let me explain..
Lets say I create a webpage for Factories.
This means that several customers that own these Companies that run the factories would like to use this system.
Company A has 3 Factories with 100 workers on each factory.
Company B only has one factory with 20 workers on that factory.
I have read alot of roles and that of sort on how we could seperate these by roles. What they can see, what they can do. But how in the world do I isolate Company A from Company B?
The old fashioned SQL table way would be like to have a Users table, a factory table and a perhaps Customers table. And from there build the logic. But with Identity it does not seem to work in that way?
Any suggestions or links to further reading about this would be appriciated! And even if you guys know that Identity is not the way to go for this kind of solution, then be it. Just so I don’t waste any time on something that perhaps is not meant to be.
There’s a lot to unravel in your question, but I’ll give it a shot. At a high-level it sounds like you’re looking for a multi-tenant system.
and pretty much everything you’re saying is on point, you probably just need an example to get going. If so, check out Microsoft’s example of a multi-tenant system. It might be enough to get you going.
There’s several different approaches to a multi-tenant system depending on your business requirements, but here’s a few of the more common approaches I’ve seen used:
- Database Isolation – Each Company would be in a separate database. When a user from Company A connected, you would be able to look up which database/schema you should connect too.
- Row Level – All companies store data in the same tables, but there’s a column called something like “company_id”. Every time you query against the table, you filter on company_id based on which user is logged in.
- Instance per tenant (AKA Standalone) – On this approach you essentially have multiple web servers running, one per company. They are completely isolated from the web server all the way down to the database. This can be desirable in some situations, but requires a bit more hardware. On the code side, you can handle this fairly effectively with just moving relevant settings into the appsettings file.
- Identity Management In Multitenant Applications
- Multi-Tenant Patterns on SQL Databases
- Row Level Multi-Tenant Example
The implementation for the different companies changes depending on how you decide to implement the multi-tenant system. So it’s hard for me to give you any concrete advice on implementation.
The only word of warning I’d give is think through the relationship between a user and a company. That could change/complicate your implementation fairly quickly.
Can a user be part of Company A and Company B at the same time?
Hope this helps a bit, and best of luck.