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 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".

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