Multi tenant explained

A multi-tenant application provides a way to deliver a service to multiple companies (known as tenants) with the minimum of hosting costs. It does this by storing each tenant's data using a tenant key (this is known as the DataKey in the AuthP library) and only that tenant can access its data. See the diagram below for an example of how this works.

The multi-tenant AuthP library parts

The AuthP library contains a entity class called Tenant, which can be used for defining a DataKey in a multi-tenant database. Its the job of the Tenant to define the name on the tenant, which is stored in the TenantFullName property and a string DataKey for each tenant.

The AuthP's provides two types of multi-tenant database:

• SingleLevel: This means each tenant is completely separate from other tenants. This is the typical way most multi-tenant databases are arranged.
• HierarchicalTenant: This means each tenant can create sub-tenants which allows a manager the access the sub-tenants data. This is useful if you need a groups sub-tenants into groups so that they can be managed as one, e.g. managing the stock across a specific geographical area.

NOTE: I would strongly recommend Microsoft's documentation about multi-tenant systems. This article covers all the different approaches to multi-tenant applications, including a comparison of each approaches.

Defining multi-tenant structure

The multi-tenant part of AuthP is handled by creating a Tenant for each different grouping of data.

SingleLevel multi-tenant

In an application using the SingleLevel multi-tenant setting, then Tenant has a unique key and the data is never shared between other tenants. So the tenant names might be:

• Company1
• Company2
• Company3
• and so on...

HierarchicalTenant multi-tenant

If the application using the HierarchicalTenant multi-tenant setting, then one Tenant can link to a another tenant. This provides the 'higher' tenants to look at the data in the 'lower' tenants. So the tenant names might be:

• Company1
  • West Coast
    • SanFran shop1
    • SanFran shop2
  • East Coast
    • ... and so on
• Company2
  • London
    • ... and so on

Company1 and Company2 in this hierarchical setup are completely separate, but within each company users with a higher level can see data in the lower levels, e.g. a user linked to the "Company1" tenant can see all the data in Company!, while a user with a tenant of "Company1 -> West Coast" can only see the "West Coast", "West Coast -> SanFran shop1", and "West Coast -> SanFran shop2".

The concept of an "Tenant Admin" user

When building a multi-tenant application its useful to define a user to manage the users within a tenant. This type of user is referred to as a tenant admin user. The AuthP library has two features to make this work:

• If a tenant admin user Lists the AuthP's users, then they will only see users with have a matching DataKey of the tenant admin. This also work with hierarchical Multi-Tenant as it knows about the different levels, which means you can have an tenant admin user for "West Coast" and a different admin user for "East Coast" etc.
• In multi-tenant applications the Role's RoleType comes into action.
  • Roles with a RoleType of HiddenFromTenant contain advanced permissions and mustn't be used in a tenant user, so they aren't visible to an tenant user.
  • Roles with a RoleType of TenantAutoAdd can be linked to a Tenant (zero to many), which cause that Role to automatically added to every user in that tenant.
  • Roles with a RoleType of TenantAdminAdd can be linked to a Tenant (zero to many), which allows the tenant admin user to assign that Role to a user in their tenant.

These Role Types are designed to allow to have different versions of your application, e.g. Free, Pro, Enterprise, by adding TenantAutoAdd and/or TenantAdminAdd type Roles to Tenant to give them extra features. Read the Part 3 article in the series "Building ASP.NET Core and EF Core multi-tenant apps" for more on versioning your multi-tenant application.

Understanding AuthP's Tenant class does

The Tenant class contains information that defines the multi-tenant data. To create a new Tenant you have to provide a unique name e.g., "Company XYZ", and once created the method GetTenantDataKey() will return a unique string, known as the DataKey. This DataKey is what defines the unique 'slice' of your applications data.

Once an AuthP user has a Tenant class linked to it, then the AuthP's will automatically add a DataKey claim to the ASP.NET Core user. This allows you to send the DataKey claim value to your application's DbContext via the AuthP IGetDataKeyFromUser service (see GetDataKeyFromUser class) to filter your various entity classes using EF Core's Global Query Filters. How you do that is explained in the creating a multi-tenant app documentation.

The Tenant class also has a many-to-many link called TenantRoles to AuthP's Roles. This allows tenant

NOTE: If user hasn't got a Tenant class linked to it, then that user can't access any of the multi-tenant data.

There are two examples of multi-tenant applications you can run:

• Example3, which implements a single-level multi-tenant application.
• Example4, which implements a hierarchical multi-tenant application.

Additional resources

• Multi tenant configuration
• Creating a multi-tenant app