Yet another question regarding tenancy and data access across tenants

[ThomasVague]

Hi, so I've seen some questions around here regarding accessing data across tenants and letting a user be associated with multiple tenants, but I feel that question has been raised in the context of a user belong to one of the customers of the company (that are selling this service). If you catch my drift.

But I want to raise the question in a different context. Shouldn't I as the DevOps / developer of my company be able to access the data accross all tenants for customer service, debugging, just general support? Shouldn't there be a "super admin" access in order to view all the tenants data (i.e. products, brands, etc..)?

Or is the idea that the Tenants-table is all that will be needed? I guess also in addition to data from Serilog which will log everything from every tenant to a logfile/server.

Or maybe it's impossible to use a new IDbContext specifically for admin purposes without the tenant/finbuckle dependency, so the global tenant filter wouldn't be applied and then some custom api endpoints for super administrators that a standalone wasm client (for example) can consume?

Am I missing something?

Anyway, really great work! Have had a lot of fun toying around with this project for a couple of days now :)

[fretje]

I don't see how you would need access to the production data as a developer... Usually you try to isolate an issue by simulating it on your development environment. If you really need the customer's data to be able to repeat a problem, I would think - worst case - you can always restore a backup of their database on your development environment... but you don't need access to the actual running production application database. And I would strongly advice against that anyway... that's why we have different environments (DEV - TEST - PROD).

A business case might arrive where you indeed need some kind of umbrella thing across all the tenants. I like to use the StackOverflow (multi-tenant app) - StackExchange (umbrella app) example.
So what you want to build is StackExchange in this case. Which is a totally separate application with its own database. It might peek inside the separate tenant's databases to aggregate some things, but for the most part it has its own application and business logic, which is separate and different from the individual tenant's application and business logic.

Keeping things separate will also help with cleaner and less complex code on both sides I think... and is overall easier to reason about IMO.

[ThomasVague]

Ok, maybe that was a bad example. I won't need it as a developer, but definitely as a customer support person. I think it's wierd you write that a business case "might" arrive, because every business selling a product need to have an administrative / support service for it's application. I don't want a "StackExchange" application (I'm not entirely sure if I even know what that means), because all the administrative and support actions are based on the data from the tenants. Take analytics data across all tenants for example. How would you approach this? Thanks.

[fretje]

Well, then please, give an actual concrete example of what a support person would do where he/she needs to be able to log in to the actual application of the customer.

Because most things I can think of that customer support is doing is helping users through some scenario where they have trouble with (mostly due to no experience or training or bad documentation)...
Being able to log into the application isn't going to help that user, most of the time the support person is going to take over the user's screen and showing them how to get through it or which options to change where. If you would go in as a "superuser" and do it for them "behind their backs" so to speak, you'll have to do that each time, in stead of learning them how to do it (or update the documentation or sell some training).

If there are actually some things that would come up regularly where a support person would need to be able to log in, that would be a sign that there's a problem in the software and it should be addressed.

Now I can imagine that in the end there would still be some things left where the support person needs to have access to (a subset) of the application's data across tenants (the business case that "might" arrive I was talking about), but those would be very few and IMO do warrant a separate "customer support" application with its own authentication only accessible by the support people.

I mean take Office365 for example as another multi-tenant application. If you're calling customer support (Microsoft in this case) with a problem. Does that support person needs to be able to log into your Office365 tenant for anything? I don't think so.

[ThomasVague]

Thanks for the quick reply.

I don't necessarily mean that you log in to the actual tenant when helping with support, but that there is a interface for a customer support person to do administrative tasks where the data is not restricted in a manner it would be for a regular tenant user.

I suppose a separate customer support application makes most sense because of the reasons you specify. Let's say that was the case, how do you think the best way would be about implementing this? Would you create one more webapi in this solution and then expose a new dbContext where the tenantContext is not set as it is now (so that the global tenantId filter wouldn't be applied etc). Is that even possible?

Im' just really curious how to solve this in the most pratical manner, because this is a hurdle I'm not entirely sure how to solve should I use this project as a base for further development where I work. And I really like everything you guys have created here. Thanks.

[fretje]

Hard to tell without an actual example. I think it would have to be considered on a case by case basis.

I would think dapper is a good tool for something like this... no need to create entities and contexts... just drill down to the actual data you want for the use case at hand.

It's definitely possible to use ef core like you describe, but remember that disabling the query filters alone is not enough, as the different tenants can all reside in their own separate database if you configure it like that. Or even a mix of the two. You will have to query across databases, which is still possible of course... just more work, so good to keep it in mind when deciding on which technologies to use.

Some use cases might even warrant a separate data-aggregation tool which runs periodically and creates an aggregated view of the needed data in a separate database which can then be used by your support application, or other reporting tools and what not.

[ThomasVague]

Yeah, that's a good point regarding the possibility of multiple databases. Our current solution is one database for all tenants, and I don't think we have any immediate plans to support per-tenant-database, but I suppose it's a good idea to "plan for the future", should that change.

Thanks for the help! Keep up the good work :)

[kallievz]

Hard to tell without an actual example. I think it would have to be considered on a case by case basis.

I would think dapper is a good tool for something like this... no need to create entities and contexts... just drill down to the actual data you want for the use case at hand.

It's definitely possible to use ef core like you describe, but remember that disabling the query filters alone is not enough, as the different tenants can all reside in their own separate database if you configure it like that. Or even a mix of the two. You will have to query across databases, which is still possible of course... just more work, so good to keep it in mind when deciding on which technologies to use.

Some use cases might even warrant a separate data-aggregation tool which runs periodically and creates an aggregated view of the needed data in a separate database which can then be used by your support application, or other reporting tools and what not.

Hi fretje.

Currently we sit with the same conundrum. But real world example. Without divulging too much, i would like explain. Like in a city that supply services. Let say, city have 9 areas, broken up in sections of 3 regions. now, the areas is set up as tenants in this case,regions is grouped by 3 areas. Some Users, will have oversight, readonly across all 9 areas(all 3 regions). Some users have viewonly on 6 areas(2 Regions), and CRUD on 3, ie, 2 regions vieving rights, and 1 region edit rights. Doing inspections all across the city, then a set of users will have to approve the work done, and assign work, depending on the regions and area's othe users are linked to.

In my own app, i am trying to create tenantgroup logic, with a sperate controller that disable multitennancy flag, and inner join on tenant on tenant group. Problem is, how do i switch user to "log in" under new tenant/area, without loggin user out first. Need to re-apply permissions on every switch, to cater for crud/viewonly permissions