Skip to main content
Version: 2.0.0

Multitenancy

What is Multitenancy?

At its core, multi-tenancy allows every part of the service (i.e., every microservice) to cater to multiple customers without deploying separate instances for each. Read more in our blog.

Most modern applications, especially microservices-based ones, require some degree of multi-tenancy.

There are advantages of using multi-tenancy:

  • Allows a secure and compliant access separation.
  • Allows the application to serve multiple customers at once - while sharing the underlying infrastructure and services.
  • Allows for load balancing and scaling.

An authorization layer is the most robust and fastest way to upgrade from a single-tenant application to a multi-tenant application safely. By applying a policy across all the relevant services, the authorization layer can apply the needed separation without requiring changes to the services themselves.

Tenants in Permit.io

Tenants in Permit.io are a first-class citizen; which means you get all the interfaces (UI, SDK, and API) to manage them out of the box. Often a tenant would represent an end-customer of yours, but sometimes you'd want multiple tenants to represent a single logical customer tenant (for example if you have multiple departments within each logical tenant). Tenants are nested under environments

Silos of Resources and Users

The easiest way to think about tenants is as a silo of resources and users; which in policy terms means only users within a tenant can act on the resources within the tenant. Tenants are isolated from one another.

info

In Permit, tenants are part of the facts (aka data) layer. This means you can assign users to tenants, but you can't have different policies for tenants' roles.

If you need to create schema isolation of tenants' roles in Permit, you can use our Project and Environment hierarchy or utilize the role attributes API-based feature.

Assigning Users to Tenants

Users are assigned to tenants via a role.

Tenant Resources

To indicate a instance resource belongs to a tenant simply provide the tenant key (or id) as part of the resource object when calling permit.check(). NodeJS example (same concept applies in other languages):

const permitted = await permit.check(userKey, "create", {
type: "document", // The resource name
tenant: tenantKey, // The tenant key
});

Resource types (as opposed to resource instances) are part of an environment, and not a specific tenant.

Tenant APIs

Tenant UI

The user-management interface includes tenant management; top left selector allows both switching tenants, editing their names, and creating new tenants.