Multitenancy Explanation

[magic-city-code]

Can someone explain multitenancy in FSH for me? There are a few bits which I do not understand. Once I understand this I am happy to create the documentation. I would like to develop a Saas for fun and this is a great starting point, but multitenancy seems lacking or maybe it's just I don't understand how it is implemented in FSH.

What I understand:

• I assume this is created with Multitenant Applications in Azure
  in mind.
• New products created are assigned to the root tenant. But how does this work?
• When registering a new user they are automatically assigned to the root tenant.
• I can create new tenants.
• I see there is a tenant header to set a tenant name in the HTTP request in post man.
• TenantMiddleware gets the tenant from the HTTP header key titled tenant to set the tenant for all API requests.

Questions:

• Is multitenancy still a work in progress?
  • The tenant header in products/search postman collection is beta.
• How do I assign users to a specific tenant?
• Can a single user belong to multiple tenants and actively switch between tenants?
• Can multiple tenants share the same database?
• There is no check that the users is authorized to use the tenant they provide. Am I wrong here? Should there be a db table that tells what all tenants the user is authorized to use?
• Why not use the tenant id in Product tenant column instead of the tenant name?

Functionality I am looking for in multitenancy is:

• During reservation a new tenant is created for the registered user. It looks like I would modify IdentityService.RegisterAsync() to create a new tenant and set the user as an admin of the tenant.
• User can belong to multiple tenants and switch between tenants in the application.
• Data shared with all tenants exists in the root tenant. It looks like to accomplish this I would need to add a global filter to the db context. modelBuilder.ApplyGlobalFilters<IIdentityTenant>(b => EF.Property<string>(b, "root") == Tenant);.

[fretje]

Coincidentally there's been a similar discussing going on yesterday on the webapi discord channel.

The multitenancy story is indeed still a work in progress. I would personally vote for adapting a library for something like this in stead of trying to roll our own. Finbuckle.MultiTenant seems to be a good one. Tried and tested and even supported by the .NET Foundation.

That said, I think you have a few misunderstandings about multi tenancy.
A single user is always connected to one single tenant. You have to see multiple tenants as multiple different businesses which have their own data, and hence their own users in the database. There's no such thing as sharing or switching users between tenants.
The same database can be shared between tenants indeed... but that's just how it's configured behind the scenes. The data is still isolated to the different tenants in any case.
So a user can not log into other tenants than for which his account is. Actually, the user shouldn't even be bothered by choosing a tenant. This should be automatically handled by through which domain/subdomain the user is connecting to the app or something like that. In that Finbuckle library, there's different "strategies" one can configure wrt how the tenant is determined.

About the tenantid/name in the product tenant column. That's actually the tenantkey in our case. But anyway, this should actually not be visible on the Product entity. That Finbuckle library attaches the "tenantId" property as a shadow property to all the entities and takes care of it behind the scenes without it being in the way of the developer... which is a much nicer experience imo.

A tenant is never automatically created. Creating a tenant is the responsibility of the owner of the app that rents out its application to that tenant. When a tenant is created, one admin user is automatically provisioned for that tenant which can then be used by that tenant's administrator to create more users or assign roles to users that are registered through the self-register process if that's enabled for that specific tenant.

So there's also no data shared between tenants (and there shouldn't be). There's the tenant table itself which could be extended to add more information you want to keep per tenant, but that's it.

When you are using AzureAD Authentication, there's an option to specify the RootIssuer in the securitysettings. This should be set to the issuer of the root tenant in AzureId. When someone is logging in from that AzureAD tenant, the local root tenant will automatically be selected.
For the other tenants there's an "issuer" field in the tenants table to map those. There's still a part which has to be implemented for mutltiple tenants from AzureAd though, as there needs to be some kind of "onboarding" experience inside AzureAD when a new tenant needs access to you application. See https://docs.microsoft.com/en-us/azure/architecture/multitenant-identity/signup for more info about this.
In any case, with AzureAD, when a user logs in and there doesn't exist a local user yet in the local tenant for that AzureAD user/tenant, one gets created automatically (only in that local tenant). It will also have the same roles assigned like the ones in AzureAD.

[frankyjquintero]

I understand part of the biggest problem that Ludwig Kruger exposes, and it is something that I have already had in another previous project, we were able to implement this concept because there was only one database and we could outsource the authentication service the detail with what you are looking for is that this would limit the ability of a business to have its own database while a parent business is in another, since the separation is already at a more drastic level to be able to control it.

As a solution that could be offered would be what fretje exposed where a single management was given to the idenntity tables and multiple tenancy would not be applied to these

[mikecasas]

@Ludwig-Kruger When the business owner logs in, do you want them to see the data for all the businesses they own?

[Ludwig-Kruger]

@mikecasas, yes of course. But with a deliberate selection of context (one tenant at a time). I see it happening the following way:

• User authenticates (username, password, captcha, 2FA)
• User chooses from available tenants (businesses) linked to the user (if only one is linked, then use it by default, no need to choose it manually)
• Authorization (Roles, Claims, Tokens, etc)

In my humble opinion, the GetTokenAsync method is breaking the Single-responsiblity Principle by trying to mash Authorization and Authentication into a single call. It is even raising Unauthorized exceptions, before authentication has succeeded. I suggest Authentication should be discreet and successful before Authorization is done in a subsequent discreet method call.

But I understand the Tenant pattern has not been designed in this way.

[fretje]

IMO the api should only do authorization and authentication should be a totally separate system, like it is now working when using Azure AD authentication. This could also be done with IdentityServer of course. It's the only "safe" option at least.
The "home brewn jwt authentication" definitely has some major security issues... I wouldn't trust it in a production system.

I don't think GetTokenAsync is doing any authorization... It's throwing unauthorized exceptions, sure, but don't get misled by the name... at that point it's only doing authentication. The authorization is fully taken care of by the AddJwtBearer call in auth\startup.

The "Auth" folder is now called like that because I had initially put the tokenservice in there as well, but then put it back under Identity and forgot to update the name again, but it should actually be called "authorization"... the only "authentication" that's happening in the app is in gettokens and refreshtokens (which should probably live in their own namespace... it has nothing to do with identity, and it is also not authorization... but like I already said... they should actually live in their own service. This is even mandatory if you want to be able to access multiple api's (e.g. microservices) with the same access token.

Having said all that... I think multitenancy (like it's implemented now with the finbuckle library) is super flexible with regards to all that. You can decide where you put the multitenancy middleware (in front or after authorization) and if you want the identity tables to be multitenant or not. You can design it any way you want (which was not so straightforward before the move to finbuckle).

[Ludwig-Kruger]

Thank you for the input.
I will experiment with the new multitenancy to see where it falls short for our scenario.
But it does seem that the "A single user is always connected to one single tenant" rule has become flexible.
Your commitment to this project is very much appreciated, thank you.