Multi-Tenant Users #248
|
Are there any plans to implement super users that can CRUD data across all tenants? Or is the expectation to just have an admin per tenant act as the super user, and you have to log out and reselect a tenant to administer that tenant? Thanks in advance, love the work! |
Replies: 1 comment 7 replies
|
I think there will never be a business requirement to enable a user outside the tenant boundary to be able to edit/add data to the tenant-specific data set. The maximum permission you can give to the root tenant admin is, will be to monitor the DB usage, entity count, and stuff (Querying only). I don't think it will be implemented in this boilerplate. As you said, the tenant Admin is and should be only authorized to be the super admin of the teanant. |
|
I think this is another mixup between multitenant and multi-somethingelse... if your root tenant is a marketplace, then all other tenants are also marketplaces. With each their individual "Shops" in this case. If you model it like that, then you can let users have access to multiple shops within one marketplace (tenant)... Multitenancy is all about sharing code and infrastructure... not data. |
|
I think the business case still exists, but I also think that @fretje's reasoning also works as a work around, it's just not ideal, and if people choose this route the multi-tenancy feature of this solution is basically not used, and can end up being a hassle, and therefore not totally clean architecture as you have a massive feature set that is not in use. Multi-tenancy is a single bit of software (and infrastructure) that serves multiple customers. And proper implementation means that each customer is properly separated. Sure, you can just have one tenant, and use 'multiple shops'. But I think there is also a case to be had for a super user that is somewhat transient across tenants, not just entities within the tenant. My worry was primarily around support for the tenants. The use case for say, a support engineer to manage multiple tenants data mishaps or higher level data stuff is in my opinion, very strong. The alternative is that you'd have multiple support user logins for each tenant. Which is fine, but still a work around. How do you safely audit this? How do you ensure and report the support engineers identity? You'd have to create x support accounts for n tenants, which is a lot of overhead. The current implementation only works if each tenant is expected to manage their data on their own, and expect no support from the actual implementer of the software, which seems kind of bad to me. I dunno, I mean, it works as is. I see both sides of the argument. Just thought I'd bring by thoughts on the matter to the discussion. |
Until you (or the owner of the software) all of a sudden would like to sell a whole separate "marketplace" to an individual customer, which in turn can create as many shops he wants inside it... Multitenancy is usually something that is in the way first... as long as you're running a single business from it. It's only when the case arises that you would like to support multiple businesses... if you then at this point have to bolt multi-tenancy onto an existing code base, that will always be more work (and probably not as good designed) as when it was there from the beginning... What is the actual application that you're building? Is it a marketplace? Then multi-tenancy gives you multiple marketplaces. I was thinking about StackOverflow. There the application is Q&A. They have multiple Q&A sites (tenants), each have their own user accounts. Later they have built an umbrella thing around it called StackExchange (and built a lot of infrastructure around that), but that's a totally separate application. Due to the fact that they are using OpenID as authentication mechanism, they can easily connect the different useraccounts from the same user across the different Q&A sites into one global stackexchange account... but I'm sure they are still separate user accounts in every single Q&A site's database... So maybe you should simply create a shop application with fsh, and then later build a "marketplace" application and infrastructure around that? Thats also an option... Not sure though... you definitely got me thinking :-) Turns out multitenancy is definitely not easy and can apparently be different for different use cases... not sure there is a "super generic" approach here we should or shouldn't apply in the base template... |
|
Yeah, it's certainly not clear cut at all. I think maybe the term multi-tenant and the baggage that term brings is sort of not appropriate here. Perhaps "B2B user" would describe the use case better? You sort of touched on it in your StackOverflow example. But technologies such as Azure AD B2B would allow you to create a sort of 'native' account on one tenant, and then allow them to collaborate with other tenants. This as I alluded to helps remove the need for admins local to each tenant, and instead invests admin power in a single user. I haven't tested this approach at all, I've never implemented this technology, only worked with already existing implementations so I'm not sure what it would take to get B2B to work... Looking at the literature though, it looks like it could be done via an Azure AD dashboard, although again, I haven't actually tried to do anything with it yet. |
|
I’d like to add to this conversation if I may. The user to tenant isn’t strictly a one-to-one relationship in many SaaS multi-tenant applications. Since the user account is most often a users email address, forcing a uniqueness on the email address leads to driving users to have multiple logins for different tenants, and since the user name is the email address we’ve now blocked the user from logging into two tenants without a separate email address, which in corporate scenarios and B2B, is basically a no-go. Ideally users are unique but can be registered as members of multiple tenants. If they are linked to one tenant then they can be logged directly into that tenant implicitly. If they are linked to multiple tenants then assuming you can’t identify the intended tenant membership then you ask the user. Forcing the one-to-one relationship gives users a headache in maintaining multiple email addresses and MFA accounts in order to login to different tenants. When we look at SSO and claims this becomes more challenging. https://softwareengineering.stackexchange.com/questions/403274/multitenancy-with-cross-tenant-users |
I think there will never be a business requirement to enable a user outside the tenant boundary to be able to edit/add data to the tenant-specific data set. The maximum permission you can give to the root tenant admin is, will be to monitor the DB usage, entity count, and stuff (Querying only). I don't think it will be implemented in this boilerplate. As you said, the tenant Admin is and should be only authorized to be the super admin of the teanant.