Multi-tenant ASP.NET Core app - tenant resolution

Primary goals

You can download the final solution from my GitHub to follow along. This solution in based on ASP.NET Core 6.

Our goals:

• The solution should be lightweight. We don't want to interfere with the framework.
• On a request level, we know within which tenant it’s made.
• The tenant name is included in the first segment of the URL. For instance, https://myapp.local/helloworld would give helloworld as a tenant name.
• Everything after the first segment should lead us to the given app route. For example, https://myapp.local/helloworld/account will route us to AccountController for HelloWorld tenant.
• Tenants will not have separated dependency container scopes.
• We should be able to get tenant-specific settings.
• User authenticated within tenant1 should not be a valid user for tenant2 (it will be done in part 2).

The shared dependency container scope may sound controversial in this case. When we inject a service registered as a singleton to tenant1, we will inject the same instance for tenant2's request. From my experience, "tenant singletons" which need to store some kind of state are not frequent. Usually, you can handle it by using internal ConcurrentDictionary with appropriate key-value pairs per tenant.

Creating tenant context

Firstly, let's start with creating the TenantContext class. It will be a simple object that holds the tenant's data and settings. We will also expose two separate interfaces responsible for getting and setting the current tenant. Why? Because we will only set up the tenant once during the request lifetime (using ITenantSetter). Everywhere else, we will use an interface named ITenantContext that allows getting the current tenant without the possibility to change it.

1public interface ITenantContext2{3    Tenant CurrentTenant { get; }4}5
6public interface ITenantSetter7{8    Tenant CurrentTenant { set; }9}10
11public class TenantContext : ITenantContext, ITenantSetter12{13    public Tenant CurrentTenant { get; set; }14}15
16public class Tenant17{18    public string Name { get; set; }19
20    public Tenant(string name)21    {22        Name = name;23    }24}

Secondly, we need to register it in a dependency container. This solution uses a built-in ASP.NET Core container that is completely sufficient for this case. To use the same instance of the TenantContext object within the given request, we need to register it with scoped (request) lifetime. What is tricky here is that the same instance needs to be registered under two different interfaces: ITenantContext and ITenantSetter.

1public static class ServiceCollectionExtensions2{3    public static IServiceCollection AddMultitenancy(this IServiceCollection services)4    {5        services.AddScoped<TenantContext>();6
7        services.AddScoped<ITenantContext>(provider =>8            provider.GetRequiredService<TenantContext>());9
10        services.AddScoped<ITenantSetter>(provider =>11            provider.GetRequiredService<TenantContext>());12
13        return services;14    }15}

After that, we invoke the AddMultitenancy extension method in the ConfigureServices within the Startup class.

We can also register controllers with views with UseEndpoints (for later). The UseStaticFiles middleware is used to mitigate resolving favicon.ico as a tenant name.

1public class Startup2{3    public void ConfigureServices(IServiceCollection services)4    {5        services.AddControllersWithViews();6        services.AddMultitenancy();7    }8
9    public void Configure(IApplicationBuilder app)10    {11        app.UseDeveloperExceptionPage();12        app.UseStaticFiles();13        app.UseRouting();14        app.UseEndpoints(endpoints =>15        {16            endpoints.MapDefaultControllerRoute();17        });18    }19}

Implementing tenant store

Subsequently, we need a tenants store. It will be a service that returns a Tenant object based on the tenant's name. We will hardcode two tenants for demo purposes.

Note that the logic inside this method can be quite complex and depends on where you store your tenants' configuration. It could be a database, JSON file, or dedicated resource on a cloud. I use Azure App Configuration to store tenants’ configurations. It is also a place to add tenant-specific configuration by extending the Tenant class with additional properties.

1public interface ITenantStore2{3    Tenant GetTenant(string tenandId);4}5
6public class TenantStore : ITenantStore7{8    public Tenant GetTenant(string tenandId)9    {10        return tenandId switch11        {12            "tenant1" => new("tenant1"),13            "tenant2" => new("tenant2"),14            _ => null15        };16    }17}

Let’s register it in the dependency container within the AddMultitenancy method.

1public static class ServiceCollectionExtensions2{3    public static IServiceCollection AddMultitenancy(this IServiceCollection services)4    {5        services.AddScoped<TenantContext>();6
7        services.AddScoped<ITenantContext>(provider =>8            provider.GetRequiredService<TenantContext>());9
10        services.AddScoped<ITenantSetter>(provider =>11            provider.GetRequiredService<TenantContext>());12
13        services.AddScoped<ITenantStore, TenantStore>();14        return services;15    }16}

Resolving tenant per request

We need to set the tenant in TenantContext in the HTTP pipeline. Let’s create custom middleware with tenant resolution logic.

It gets the first segment of the request URL (from the Host header), invokes ITenantStore to get Tenant the object, and sets it within TenantContext using the ITenantSetter interface (it is an abstraction over TenantContext). If the tenant is not found, the app returns a 404 code.

When we get the tenant object we also set PathBase and Path properties on the HttpRequest object. After that, for instance, https://myapp.local/helloworld is considered a "root path" for other routes.

Note that Middlewares in ASP.NET Core are registered as singletons! Therefore ITenantSetter and ITenantStore are injected as arguments of the Invoke method, not via the constructor.

1public class TenantResolutionMiddleware2{3    private readonly RequestDelegate _next;4
5    public TenantResolutionMiddleware(RequestDelegate next)6    {7        _next = next;8    }9
10    public async Task Invoke(11        HttpContext context, ITenantSetter tenantSetter, ITenantStore tenantStore)12    {13        (string tenantName, string realPath) = GetTenantAndPathFrom(context.Request);14
15        Tenant tenant = tenantStore.GetTenant(tenantName);16
17        if (tenant == null)18        {19            context.Response.StatusCode = 404;20            return;21        }22
23        context.Request.PathBase = $"/{tenantName}";24        context.Request.Path = realPath;25        tenantSetter.CurrentTenant = tenant;26
27        await _next(context);28    }29
30    private static (string tenantName, string realPath)31        GetTenantAndPathFrom(HttpRequest httpRequest)32    {33        // example: https://localhost/tenant1 -> gives tenant134        var tenantName = new Uri(httpRequest.GetDisplayUrl())35            .Segments36            .FirstOrDefault(x => x != "/")37            ?.TrimEnd('/');38
39        if (!string.IsNullOrWhiteSpace(tenantName) &&40            httpRequest.Path.StartsWithSegments($"/{tenantName}",41                out PathString realPath))42        {43            return (tenantName, realPath);44        }45
46        return (null, null);47    }48}

The TenantResolutionMiddleware needs to be between UseRouting and UseStaticFiles. I suppose that we have no choice! 😄

1public void Configure(IApplicationBuilder app)2{3    app.UseDeveloperExceptionPage();4    app.UseStaticFiles();5    app.UseMiddleware<TenantResolutionMiddleware>();6    app.UseRouting();7    app.UseEndpoints(endpoints =>8    {9        endpoints.MapDefaultControllerRoute();10    });11}

Let’s try our solution

For demo purposes, I created a simple HomeController. The TenantContext is injected there via its constructor. Then in the Index method, we get the tenant’s name and return it as a response content.

1public class HomeController : Controller2{3    private readonly ITenantContext _tenantContext;4
5    public HomeController(ITenantContext tenantContext)6    {7        _tenantContext = tenantContext;8    }9
10    [HttpGet]11    public ActionResult Index()12    {13        var tenantName = _tenantContext.CurrentTenant.Name;14        return Content($"Tenant: '{tenantName}'");15    }16}17
18public class HomeViewModel19{20    public string Message { get; set; }21}

To invoke the Index action, we run the application and open URLs like https://localhost:5001/tenant1 or https://localhost:5001/tenant2. It routes to HomeController. Here are the results:

Conclusion

To sum up, in this article we created foundations of multi-tenant application with a simple tenant resolution mechanism. Tenants are resolved by the first segment of the request URL. Their "context" is available within request's lifetime. In the next part of this series, we will configure cookie-based authentication.

While using this resolution strategy, you may encounter problems with static files. Consider request URL like https://localhost:5001/favicon.ico. In our solution, we added UseStaticFiles before TenantResolutionMiddleware so favicon.ico is not considered as a tenant name. In your app, you need to prepare your HTTP pipeline carefully and predict all cases like this.