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.
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
- Manage Tenants - Tenants API
- Assign a User to a Tenant - Role-Assignments API
Tenant UI
The user-management interface includes tenant management; top left selector allows both switching tenants, editing their names, and creating new tenants.