An ultimate guide to multi-tenant CIAM setup

Building a multi-tenant app can be challenging, with many aspects to consider. This article compiles all our previous blog posts on understanding multi-tenant and organization practices. For a quick start and to save time, just check out this article, it includes all you need!

The general guidelines are outlined in the following steps:

1. Understand multi-tenant architecture
2. Map your multi-tenant app use cases
3. Achieve tenant isolation
4. Define how you want to manage the identities
5. Choose the appropriate authorization models

Understand multi-tenant architecture

Software multi-tenancy is a software architecture in which a single instance of software runs on a server and serves multiple tenants. Systems designed in such a manner are "shared" (rather than "dedicated" or "isolated").

A tenant is a group of users who share common access with specific privileges to the software instance.

One of the key mindsets of multi-tenancy is “shared”. In the broader definition of multi-tenancy, being a multi-tenant application doesn't imply that every component in a solution is shared. Rather, it implies that at least some components of a solution are reused across multiple tenants. Understanding this term broadly can better help you empathize with your client's needs and where they come from.

Once you understand multi-tenant architecture, the next step is to apply your app to real-world scenarios, focusing on specific product and business needs.

Map your multi-tenant app use cases

SaaS

Multi-tenant apps often find their place in business-to-business (B2B) solutions like productivity tools, collaboration software, and other software-as-a-service (SaaS) products. In this context, each "tenant" typically represents a business customer, which could have multiple users (its employees). Additionally, a business customer might have multiple tenants to represent distinct organizations or business divisions.

Generic B2B use cases

B2B applications go beyond SaaS products and often involve the use of multi-tenant apps. In B2B contexts, these apps serve as a common platform for various teams, business clients, and partner companies to access your applications.

For instance, consider a ride-sharing company that provides both B2C and B2B apps. The B2B apps serve multiple business clients, and employing a multi-tenant architecture can help the management of their employees and resources. To illustrate, if the company wishes to maintain a unified user identity system, it can design an architecture like the following example:

Sarah has both a personal and a business identity. She uses the ride-sharing service as a passenger and also works as a driver in her spare time. In her professional role, she also manages her business and uses this business identity to be a partner with Business 1.

Why should you employ multi-tenancy in SaaS product

Scaling with multi-tenancy

For enterprise businesses, multi-tenancy is the key to effectively fulfilling their requirements for availability, resource management, cost management, and data security. On a technical level, adopting a multi-tenant approach streamlines your development processes, minimizes technical challenges, and promotes seamless expansion.

Creating a unified experience

When examining the roots of SaaS products, it's akin to a building housing various apartments. All tenants share common utilities like water, electricity, and gas, yet they maintain independent control over managing their own space and resources. This approach simplifies property management.

Ensuring security through tenant isolation

In a multi-tenancy architecture, the term "tenant" is introduced to create boundaries that separate and secure the resources and data of different tenants within a shared instance. This ensures that each tenant's data and operations remain distinct and secure, even if they are utilizing the same underlying resources.

Achieve tenant isolation

When discussing multi-tenant applications, it's always necessary to achieve 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). 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 and the best practice to achieve tenant isolation.

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.

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?

Here is the thing, 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.

Use “organization” to represent the SaaS product tenant, for achieving tenant isolation

Relying solely on authentication and authorization won't prevent a user with the right role from accessing another tenant's resources. So we need to incorporate a “tenant” context, such as a tenant ID, to restrict access to 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.

Identities in multi-tenant 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.

1. 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).
2. 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

This answer can guide your system design. For a brief response concerning a multi-tenant app,

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.

Choose the authorization models for better access control

Choosing and designing the appropriate authorization model

When selecting the right authorization model, consider these questions:

1. Are you developing a B2C, B2B, or a combination of both types of products?
2. Does your app have a multi-tenant architecture?
3. Is there a need for a certain isolation level in your app, as determined by the business unit?
4. What permissions and roles need to be defined within the context of the organization, and which ones are not?

Understand different authorization models in Logto

Role-based access control

RBAC (Role-Based Access Control) is a method for granting user permissions based on their roles, enabling effective management of resource access.

This common technique underpins access control and is a key component of Logto's authorization features. As a comprehensive identity management platform, Logto offers tailored solutions for various layers and entities, catering to developers and businesses for diverse product architectures.

API role-based access control

To protect general API resources that are not specific to any organization and don’t need context restrictions, the API RBAC feature is ideal.

Just register the API and assign permissions to each resource. Then, control access through the relationship between roles and users.

API resources, roles, and permissions here are “democratized” under a unified identity system. This is pretty common in the B2C product with less hierarchy and doesn’t need a very deep level of isolation.

Organization role-based access control

In the B2B and multi-tenant environment, tenant isolation is necessary. To achieve this, organizations are used as a context for isolation, meaning RBAC is effective only when a user belongs to a specific organization.

Organization RBAC focuses on controlling access at the organization level rather than the API level. This provides significant flexibility for organization-level self-management in the long run but still within a unified identity system.

A key feature of organization RBAC is that roles and permissions are generally the same across all organizations by default, which makes Logto “organization template” extremely meaningful for improving development efficiency. This aligns with the shared philosophy of multi-tenant apps, where access control policies and identities are common infrastructure components across all tenants (app tenants), a common practice in SaaS products.

Closing

This article provides all you need to get started with preparing and configuring multi-tenant apps. Give Logto a try today and begin applying best practices for multi-tenant app development with organizations.