How do you identify the tenant using a JWT when integrating with Autofac? - jwt

Question

I'm trying to build a multi-tenant ASP.NET Core 2.1 WebApi.
I would like to chose tenant from the jwt token and not from the url or port.
So When user Request the token, I put it's tenant_id into the token.
But when I try to resolve the TenantId in the Autofac Multitenant strategy (ITenantIdentificationStrategy) like this:
public bool TryIdentifyTenant(out object tenantId)
{
_logger.LogInformation("***********************************TryIdentify");
tenantId = null;
try
{
var context = _httpContextAccessor()?.HttpContext;
if(context != null && context.Request != null)
{
var id = context.User.FindFirst("tenantId")?.Value;
if (id != null)
{
tenantId = id;
}
}
}
catch(Exception)
{
// Happens at app startup in IIS 7.0
}
return tenantId != null;
}
I see that the context.User is not jet populated and that's because the Jwt authentication didn't happen jet.
How to do it?

Answer 1

The short version of this is you don't get to do this for free. This is generally why it's best to use something you can trust but doesn't require additional support to use (like the host name in the request).
If you can only trust the token, then I have seen solutions that roughly do this (in pseudocode-that-looks-like-C#):
if(context.Items["tenant"] == null && context.User == null)
{
// no tenant has been identified before and
// token validation hasn't happened so manually
// get the tenant from the token knowing you are
// potentially getting an untrusted value.
context.Items["tenant"] = ManuallyLookAtToken();
}
else if(context.Items["tenant_trusted"] == null && context.User != null)
{
// a "trusted" tenant ID hasn't been read from the user
// principal so let's update.
context.Items["tenant"] = GetTenantFrom(context.User);
context.Items["tenant_trusted"] = true;
}
return context.Items["tenant"];
The risk in doing something like this is that you open yourself up to an attack where someone sends in a malformed token that only lives long enough to get past the initial part of your request pipeline. The token won't pass validation so the regular security should take care of it, but before that runs the tenant value isn't officially validated. If you have pipeline logic, that, for example... auto-provisions new tenants on first request or something like that?... then you may be in trouble. Someone could randomly generate millions of tenant names and kill your database. In cases like that you can sometimes fall back to other things like the host name.
Alternatively, you can actually manually invoke the token validation logic in that ManuallyLookAtToken() method and ensure it's valid before proceeding. It's sort of painful, but not impossible. That would mean technically you would run that twice during any given request, and it's sort of expensive, so consider the perf if you go that route and balance that with security implications.