English

multi-tenant
saas
software
development
architecture

Tenant isolation in multi-tenant application

Tenant isolation is a key concept in multi-tenant applications. In this article, we'll discuss what it is and how it can be achieved.

Guamian

Product & Design

11/6/20233 min read

Stop wasting weeks on user auth

Launch secure apps faster with Logto. Integrate user auth in minutes, and focus on your core product.

Get started

Hello everyone! In this chapter, we'll build upon our earlier discussions on multi-tenant topics. If you haven't read the previous articles yet, we recommend starting with those first!

When discussing multi-tenant applications, it's important to think about tenant isolation. This means keeping the data and resources of different tenants separate and secure within a shared system(for example, a cloud infrastructure or a multi-tenant application).

The goal of tenant isolation is to make sure that each tenant's data and operations remain distinct and secure from one another, even when they are using the same underlying resources.

In a Software as a Service (SaaS) scenario, tenant isolation involves creating structures within the SaaS framework that strictly regulate resource access. This prevents any unauthorized attempts to access another tenant's resources.

While the explanation might seem abstract, we'll use examples and key details to further explain the isolation mindset.

Tenant isolation doesn't go against multi-tenancy's "shared" mindset

That is because tenant isolation is not necessarily an infrastructure resource-level construct. In the realm of multi-tenancy and isolation, some view isolation as a strict division between actual infrastructure resources. This usually leads to a model where each tenant has separate databases, computing instances, accounts, or private clouds. In shared resource scenarios, like multi-tenant apps, the way to achieve isolation can be a logical construct.

Tenant isolation focuses exclusively on using “tenant” context to limit access to resources. It evaluates the context of the current tenant and uses that context to determine which resources are accessible for that tenant. It applies this isolation to all users within that tenant. Any attempt to access a tenant resource should be scoped to just those resources that belong to that tenant.

Isolation comes in different levels

When we understand that isolation isn't strictly tied to infrastructure resource levels and isn't a clear separation between physical infrastructure, it leads to a conclusion like this:

Instead of viewing isolation as a simple "yes" or "no," consider it as a spectrum. You can set up parts of your system to be more or less isolated based on what you need.

The diagram below illustrates this spectrum of isolation.

isolated shared

Authentication and authorization are not equal to “isolation”

Using authentication and authorization to control access to your SaaS environments is important, but it's not enough for complete isolation. These mechanisms are just one part of the security puzzle.

People often ask a question, can I use general authorization solutions and role-based access control to achieve tenant isolation? You can build a multi-tenant app but you can’t say you achieved and employed tenant isolation strategies as a best practice. We don’t generally recommend it because

To illustrate, consider a situation where you've set up authentication and authorization for your SaaS system. When users log in, they receive a token containing information about their role, dictating what they can do in the application. This approach boosts security but doesn't ensure isolation.

Now, here's the catch: Without incorporating “tenant” context, such as a tenant ID, to restrict access to resources, relying solely on authentication and authorization won't prevent a user with the right role from accessing another tenant's resources.

This is where tenant isolation comes into play. It uses tenant-specific identifiers to establish boundaries, much like walls, doors, and locks, ensuring a clear separation between tenants.

Identity in multi-tenancy apps

We discussed tenant isolation, but what about identities? How do you decide if your identities should be “isolated” or not?

There's often confusion around the concept of "identity isolation." It could refer to situations where one real-world user has two identities in people’s general understanding.

Both identities can exist within a single identity system. For instance, Sarah might have a personal email registered alongside a corporate email connected through single sign-on (SSO).
Users maintain two distinct identities within separate identity systems, representing entirely separate products. These products are completely unrelated to each other.

At times, these scenarios are referred to as "Identity isolated." Yet, this label might not assist in making a decision.

Rather than determining if you require "identity isolation," consider whether you or a segment of your business or product need to maintain separate identity systems. This answer can guide your Identity and Access Management (IAM) system design. For a brief response concerning a multi-tenant app,

In most cases, in multi-tenant apps, identities are shared while each tenant's resources are isolated.

In multi-tenant applications, identities, unlike tenant-specific resources and data, are shared among multiple tenants. Picture yourself as the building administrator; you wouldn't want to maintain two separate name sheets to manage your tenants' identities.

When aiming for tenant isolation, you might have observed the recurring emphasis on the term "organization," often regarded as a best practice for building multi-tenant applications.

By employing the notion of "organization," you can achieve tenant isolation in your multi-tenant application while maintaining a unified identity system. This allows multiple "organizations" to coexist, independently, but share tenant-agnostic resources within the application. Similar to residents living in a building, each organization utilizes the application without concern for their neighbors, as the "organization" provides the necessary separation in the form of walls, hallways, doors, and locks. They share the overall building infrastructure, interior design system, and various tangible or intangible components.

Logto is introducing the “Organization” feature in November

Logto is currently in active development of the "Organization" feature, aiming for a Nov 2023 launch. This feature is specifically crafted to meet the tenant isolation requirements necessary for building a SaaS product, aligning with industry standards and best practices.

In the upcoming chapter, we'll delve deeper into the "Organization" feature and how Logto facilitates the implementation of best practices for building a multi-tenant application.

Try Logto today

Tenant isolation doesn't go against multi-tenancy's "shared" mindset#

Isolation comes in different levels#

Authentication and authorization are not equal to “isolation”#

Identity in multi-tenancy apps#

Logto is introducing the “Organization” feature in November#

Tenant isolation doesn't go against multi-tenancy's "shared" mindset#

Isolation comes in different levels#

Authentication and authorization are not equal to “isolation”#

Identity in multi-tenancy apps#

Logto is introducing the “Organization” feature in November#

Tenant isolation doesn't go against multi-tenancy's "shared" mindset

Isolation comes in different levels

Authentication and authorization are not equal to “isolation”

Identity in multi-tenancy apps

Logto is introducing the “Organization” feature in November

Tenant isolation doesn't go against multi-tenancy's "shared" mindset

Isolation comes in different levels

Authentication and authorization are not equal to “isolation”

Identity in multi-tenancy apps

Logto is introducing the “Organization” feature in November