Multi tenant explained

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.

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 at in the higher levels can see data in the lower levels, e.g. a user linked to the Company1 tenant can see all the data in that 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".

Linking a user to a specific Tenant

Each user can have a Tenant added to their AuthUser entry. This means there are a one-to-many relationship between a Tenant and an AuthUser (NOTE: a AuthUser, by default doesn't have a Tenant and won't create a DataKey claim.

Additional resources

• Multi tenant configuration