Autofac.AspNetCore.Multitenant | Enables multitenant dependency injection support | Dependency Injection library

Something to consider when reading the Autofac docs is that Autofac supports any application type - console app, Windows service, ASP.NET app, whatever. So when you see that the tenant can come from the user's principal... well, it can. Whether your app has it ready to go at the time is up to your app. The console might get the principal from the currently executing thread and it's already there when the app runs.

For ASP.NET / ASP.NET Core apps, there's middleware that runs to validate an inbound token, convert that token into a principal, and attach that principal to the current request.

But if you think about it... middleware has dependencies that need to be resolved from the request container, and in a multitenant system that means we need to know the tenant first thing in the middleware pipeline, not wait until the authentication/authorization bits run.

This was a problem in ASP.NET classic, too. It's not new to ASP.NET Core. I've hit it with my own apps, too.

How you solve it is going to be largely app specific - what type of token you're using, how expensive it is to validate the token, how much risk you want to take security-wise, etc.

In my most recent run-in with this, we were using signed (but not encrypted) JWT coming in. One of the claims, tid, had the tenant ID in it. What we did was decide to do some manual work on the token - validate the signature, then just grab the tid claim out of the token directly. No more parsing, no other validation (audience, etc.). It needed to be fast. We then cached the tenant ID in the HttpContext.Items so we didn't have to look it up again and so it could be used anywhere else we needed the tenant ID that ran before authentication middleware.

There was a slight risk that someone can get a different tenant's pipeline to execute from initial request up to the authentication middleware and then get rejected by the authentication middleware. We were OK with that since it was still pretty quickly going to reject unauthorized folks. That may or may not be OK for you, so you'll have to decide.

But, the long and the short of it was: Due to the race condition of needing the tenant ID before the authentication middleware has run, we had to figure something else out. It looks like you, too, are going to have to figure something else out.

"Multitenancy doesn't seem to work at all" is a somewhat ambiguous statement that's hard to address. Unfortunately, I don't personally have the time to download all of your example code and try to repro the whole thing and debug into it and see exactly what's wrong. Perhaps someone else does. However, I can offer some tips as to places I'd look and things I'd try to see what's up.

Tenant ID strategy set up twice. I see in Startup.ConfigureContainer that there's a builder.RegisterType(); line - that's going to register your strategy type as instance-per-dependency, so every time it's needed it'll be resolved fresh. I also see in Startup.ConfigureMultitenantContainer that you're manually instantiating the strategy that gets used by the multitenant container. There's a non-zero possibility that something is getting messed up there. I would pick one way to get that done - either register the strategy or manually create it - and I'd make sure that thing is a stateless singleton. (It's not registered in the example.)

Route pattern possibly questionable. I see the route pattern you have registered looks like this: {terminal}/{controller=Home}/{action=Index}/{id?}. I also see your URLs look like this: https://localhost/app/terminal1 Have you stepped into your tenant ID strategy to make sure the route parsing mechanism works right? That is, app isn't being picked up as the terminal value? Route parsing/handling can be tricky.

Possibly bad settings. The tenant ID strategy only successfully identifies a tenant if there are options that specify that the specific terminal value exists. I don't see where any of those options are configured, which means in this repo there are no tenants defined. Your strategy won't identify anything without that.

If it was me, I'd probably start with a breakpoint in that tenant ID strategy and see what's getting resolved and what's not. It seems somewhat complex from an outside perspective and that's where I'd begin. If that is working, then I'd probably also look at cleaning up the registrations so the ID strategy isn't registered twice. Finally, I get the impression that this isn't all the code in the app; I'd probably look at making a super minimal reproduction that's about the size you actually have posted here. I'd then focus on making that minimal repro work; then once it works, I'd figure out what the difference is between the repro and my larger app.

Unfortunately, that's about all I can offer you. As I mentioned, with the current environment and my current workload, I won't be able to actually sit down and reproduce the whole thing with your code. I know the integration works because I have production apps using it; and there are a lot of tests (unit and integration) to validate it works; so the part that isn't working is likely in your code somewhere... and those are the places I'd start.

At this time I don't believe Finbuckle and Autofac.Multitenant are compatible.

Autofac multitenant support for ASP.NET Core relies on running first thing in the middleware pipeline so it can set HttpContext.RequestServices to be based on the tenant scope. As part of that, of course, the tenant identification strategy is going to run.

However, Finbuckle assumes every tenant is sharing a container like the default ASP.NET Core functionality. Finbuckle middleware tries to use HttpContext.RequestServices to identify the tenant based on registered strategies.

You can see the sort of chicken/egg problem this raises - request services should be based on the tenant lifetime scope, but the tenant identification strategy requires resolving things from the request services.

However, let's ignore that for a second because the question was how to avoid the database call for identification on every resolve.

If you dive into the Finbuckle code, the middleware sets the tenant information on HttpContext.Items as part of their middleware running. Later, when you retrieve the tenant info, it gets retrieved from HttpContext.Items, not re-resolved through the database. The database call executes only once, the first time tenant ID is run.

That's probably fine. Depending on how many tenants you plan on supporting and how often they change, it might be worth adding some sort of in-memory caching layer you could use to store tenant ID data (whatever is stored in the database that helps you identify that tenant) so you can try the in-memory store first before hitting the database. Maybe it periodically expires data in there or maybe it's a fixed size or whatever... the caching strategy is entirely app-dependent and there's no way I could ever recommend specifics around that. Point being, that's one way to alleviate the database call.

But getting back to the chicken/egg problem, I don't see an easy way around that.

If it was me and I had to get this working, I'd probably skip calling the IApplicationBuilder.UseMultiTenant() extension and then create my own version of their middleware which, instead of using HttpContext.RequestServices to get the tenant ID strategies, would take a multitenant container right in the constructor like the Autofac multitenant middleware and would directly use the application-level container to resolve those strategies. That would, of course, have to run before the Autofac multitenant request services middleware, and forcing middleware order is sort of painful. Finally, since the HttpContext.Items would end up having the tenant identification after that middleware runs, your Autofac ITenantIdentificationStrategy could simply look there to get the data and not call the database at all.

However...

HUGE, AMAZINGLY IMPORTANT DISCLAIMER

• I have never in my life used Finbuckle. I can browse the code on GitHub but I don't know what side effects the above consideration might have.
• I haven't actually tried the above consideration. It may not work.
• I'm an Autofac project maintainer and wrote the original multitenant support including the original integration with ASP.NET Core. It was very painful to get it to work... so when I say the above consideration might be tricky, I've been there.
• I very specifically call this a 'consideration' - something to consider - and not a recommendation because I'm not going to necessarily 'recommend' something I don't have a lot of confidence in. I don't have confidence because, again, I don't use Finbuckle.

MY ACTUAL RECOMMENDATION is... well, to slow down a little. As you mentioned, you're new to this area, and it seems like the stuff you're going to be running into here is pretty deep. I recommend diving into the actual Finbuckle code on GitHub if you haven't. It doesn't look like there's much and it could give you some insight as to what's going on. I recommend trying to create a multitenant app with just Autofac multitenancy, and one with just Finbuckle. See if you really need both. Maybe just one makes sense. For example, it seems like Finbuckle already has multitenancy for data storage; that's what many people use Autofac multitenancy for too - to register different database contexts for each tenant. Perhaps using just one of the products would be enough, and that could remove the whole problem.