Archives for December, 2015

Two Level Multi-Tenancy Part 2

This is part two of my series on Two Level Multi-Tenancy. You’ll probably want to read part one first.

Last time, we looked at how to use the subdomain as part of our multi-tenant MVC application and how to bring that together. Now, we’re going to look at adding the secondary layer.

For this project, we ended up with three base model classes. A base model that adds Id and DateAdded, a First Level base model that has the Level1Id, and now our Second Level base model that add an Id field for Level2 models.

Each of our EF models then inherit from the Level2 base model with the exception of that model class that inherits from the Level1 model. And so all models inherit from the Level1 base model, which will cause all of them to have our Level1 Id field.

Our routes at this point look like The project has a helper method that pulls the Level2 value from the route.

I also added another base controller, which again inherits from our Level1 base controller we set up in part 1.

public class Level2BaseController : Level1BaseController
    protected string Level2Name => GetFromRoute();

    protected override void OnActionExecuting(ActionExecutingContext filterContext)
        if (string.IsNullOrEmpty(Level2Name))
            filterContext.Result = RedirectToAction("Index", "Home");

        var identity = Thread.CurrentPrincipal.Identity as ClaimsIdentity;
        if (!identity.IsAuthenticated) return;
        var claim = identity.Claims.FirstOrDefault(c => c.Type == CustomClaims.Level2Id);
        if (claim == null || (claim.Value != Sessions.Level2Id.ToString())) Users.AddL2Claim(Level2Name);

Read More

Two Level Multi-Tenancy Part 1

Recently, I’ve been working on a multi-tenancy project. Like most projects I tend to gravitate towards, it wasn’t that simple.

For those of you who know don’t know what that means, multi-tenancy is when an application is designed to be used by multiple companies/users at the same time, keeping all data separated from each other.

Typically if you want something like this done, you add a ClientId or some other restriction to your Models to help identify which tenant that Thing belongs to.

In the world of Entity Framework, you’d probably do Thing.Where(x => x.ClientId == clientId). You’d do this for each select statement, each update, and each delete to verify that the client that was logged in had the correct permissions to that resource. That’s boring, annoying, tedious and prone to errors.

Enter stage left comes Entity Framework interceptors. EF interceptors do what you’d expect them to do and intercept your EF queries before they hit the SQL server. Because they do this, it is possible to manipulate or log those queries.

Following some code by Charalampos Karypidis, I was able to get the basics setup. Because the rest of this article is an expansion of Charalampos’ code, I’ll not be reposting parts of his code that I didn’t change. You’ll want to go read and understand his article (or get the code on GitHub) before continuing. 

Where I part from Charalampos’ code is where I think things get interesting. Charalampos’ setup involves using the interceptor to assign TenantId to the UserId. That’s all fine and well, but what if there is actually a group of individuals all utilizing the same Tenant?

Read More

About Me

Hello, I’m Jonathan Peterson (aka Eonasdan)! I’m a web developer and CEO of Paladin Cloudware.

I have over 10 years of experience developing a wide array of web applications and websites. In my free time, I contribute to several open source projects.

As a die-hard developer, you’ll find me programming in my head on the rare occasions when I'm without an Internet connection.

Find me on:


telerik, MVC, Entity Framework, ReSharper, Tips And Tricks, less, grunt, C#, visual studio, code quality, NuGet, visual studio 2015