Cloud-based SaaS solutions, as well as most other solutions, need multi-tenancy. Let’s quickly review what Multitenancy is, what we can gain from it, and how to easily implement it with two simple layers.
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.
For a SaaS solution to scale affordably, meet customer demands, and be elastic in doing so (i.e., cost-effective in cloud resources), it has to support multi-tenancy.
A multitenant architecture provides many great and often essential features:
Allowing the application to serve multiple customers at once while sharing the underlying infrastructure and services
Secure and compliant access separation
Load balancing and scaling
The two layers of Multitenancy
At the end of the day, multi-tenancy is easy once you understand it, and it basically requires only two things: Application level access control and managing data schemas.
Let's break it down into two planes:
The data plane is all about how you transmit, store and manage the siloed data (i.e., How the underlying infra avoids mixing up the data of different tenants). Multi-tenancy for the data plane is often implemented as partitions on the data layers - e.g., separate partitions, tables, columns, identifiers, and/or labels on the data storage schema (how you save it in the database) and topics (e.g., Kafka topics), tags, domains, sockets, and/or ports, for the data at transit.
Example of DB tables with simple column-based tenant separation
The application plane is about how you silo context and access within the logical layer, i.e., have the same code work for different tenants. Authorization is the component within the application plane implementing multi-tenancy.
Example application route enforcing multitenancy with Permit.io’s SDK (check it out on Github)
Implementing multi-tenancy
An authorization layer is the fastest and most reliable way to upgrade from a single-tenant application to a multi-tenant one safely. In addition, the authorization layer can implement separation without requiring changes to the services themselves by applying a policy across all relevant services.
Choosing the right policy model can simplify this transition even further, with classic models like RBAC + Tenancy, ReBAC + Hierarchy (tenants becoming root-level relationships), or plain vanilla ABAC (with tenancy as an attribute).
The great thing is we don’t need to implement multi-tenancy authorization on our own, and instead can enjoy ready-made open-source tools and services.
Implementing multi-tenancy with OPA + OPAL (Open-Source)
Open source is a great option to start implementing your authorization layer for multi-tenancy. While there are multiple options, Open Policy Agent (OPA) is among the most promising.
OPA acts as an authorization microservice that we can add to our application and use to enforce access with rules written in its proprietary Rego language.
Combining OPA with OPAL (Open Policy Administration Layer) enables us to manage our authorization layer in scale, using Pub/Sub topics to keep our agents up to date with policy (Rego code) and data (JSON documents). The topics, for example, can be our tenant names or IDs, allowing us to sync our agents with changes per tenant.
Implementing multi-tenancy with Permit.io (Service)
App authorization solutions solve the application aspect out of the box and layer easily on-top of the data plane by providing (or correlating according to) unique identifiers that can be used to partition the data plane.
Permit builds on top of OPA and OPAL, adding management interfaces, including a tenants list, tenant resource management, and per-tenant user management.
Switching between tenants in Permit.io’s dashboard
To sum things up -
Multi-tenancy allows our application to cater to multiple customers without deploying separate instances for each. Multi-tenancy enforcement in gist consists of two planes: data and application. One of the best ways to achieve Multi-tenancy is by creating an authorization layer that can implement separation without requiring changes to the services themselves. Although you can build your own authorization layer, there are also open-source options (Such as OPA + OPAL) and Services (Such as Permit.io) that allow you to implement one in your application - making the critical shift into multi-tenancy more accessible.
Considering multitenancy for your app? Got questions? Join our Slack community and chat with fellow developers building authorization!
Written by
Or Weis
Co-Founder / CEO at Permit.io
