Building a multi-tenant SaaS isn’t easy, but in a world where your customers expect on-demand services and your engineering team wants a central codebase, multitenancy offers tremendous value. 

The hardest part is user management. Multi-tenant applications come with special user considerations:

  • How will tenants be represented in the data model?
  • How will users be created?
  • How will tenant users be kept secure and separate from other tenants?

As you might have guessed, Stormpath’s data model natively supports multi-tenant user management out-of-the-box. You don’t have to worry about building or managing data partitions yourself, and can focus on building your app’s real features. 

But, how do you build it?

We’ve created a comprehensive Guide to Building Multi-tenant Apps and this post will specifically focus on how to model user data for multi-tenancy. We will also show how to build a multi-tenant application faster and more securely with Stormpath, a cloud-hosted user management service that easily supports multi-tenant user models.

What is a Multi-Tenant application?

Unlike most web applications that support a single company or organization with a tightly-coupled database, a multi-tenant application is a single application that services multiple organizations or tenants simultaneously. Multi-tenant apps need to ensure each Tenant has its own private data partition so the data is cleanly segmented from other
tenants. The challenge: very few modern databases natively support tenant-based data partitioning. 

Devs must figure out how to do this either using separate physical databases or by creating virtual data partitions in application code. Due to infrastructural complexities at scale, most engineering teams avoid the separate database approach and implement virtual data partitions in their own application code. 

Our Guide to Building Multi-tenant Apps goes into deep detail on how to set up tenants and their unique identifiers. In this post, we will dive straight into setting up user management for your multi-tenant application.

Multi-Tenant User Management

Why use Stormpath for Multi-Tenant Applications?

Aside from the security challenges that come with partitioning data, setting up partitioning schemes and data models takes time. Very few, if any, development frameworks support multi-tenancy, so developer teams have to build out multi-tenant user management themselves.

Stormpath’s data model supports two different approaches for multi-tenant user partitioning. But first, a little background.

Stormpath Data Model Overview

Most application data models assign user Accounts and groups directly to the application. For example:

Traditional Application User Management Model:

But this isn’t very flexible and can cause problems over time – especially if you need to support more applications or services in the future.

Stormpath is more powerful and flexible. Instead of tightly coupling user accounts and applications, Accounts and Groups are ‘owned’ by a Directory, and an Application can reference one or more Directories dynamically:

Stormpath User Management Model:

A Directory isn’t anything complicated – think of it as simply a ‘top level bucket for Accounts and Groups’. Why did we do it this way?

  • Multiple applications can reference the same Directory and share users.
  • An application can ‘plug in’ to multiple directories, so multiple user populations can access the same application. This is great for our customers building a SaaS.
  • Security policies for Accounts are configured at the Directory level, giving you tighter control over security requirements.
  • You can configure changes to all of this without changing your application code

This directory-based model supports two approaches for partitioning multi-tenant user data:

Approach 1: Single Directory with a Group-per-Tenant

Recommended for most multi-tenant applications.

This design approach uses a single Directory, which guarantees Account and Group uniqueness. A Tenant is represented as a Group within a Directory, so you would have (at least) one Group per Tenant.

For example, let’s assume new user [email protected] signs up for your application. Upon submit you would:

  1. Insert a new Account in your designated Directory. This will be a unique account.
  2. Generate a compatible subdomain name for their tenant and create an equivalent Group in your designated Directory. Your ‘Tenant’ record is simply a Group in a Stormpath Directory.
  3. Assign the just-created [email protected] Account to the new Group. Any other Accounts added over time to this Group will also immediately be recognized as users for that Tenant.

We cover the many benefits of the Single Directory approach – as well as how to implement it – in the Multi-Tenant Guide , but at a high level, this approach has the following benefits:

  • A single unified user identity across many applications or services 
  • You can associate Accounts to a tenant easily: just add them to the tenant Group. You can find all users in a tenant by requesting the Group, or search across users in a tenant just by searching in that Group.
  • You can store Tenant-specific data without having to roll your own database/tables, by assigning custom data to your tenant group. This is great for tenant-specific permisions or Access Control Lists.

The Single Directory, Group-per-Tenant approach is the simplest model, easiest to understand, and provides many desirable features suitable for most multi-tenant applications. Read more.

Approach 2: Directory-per-Tenant

In Stormpath, an Account is unique only within a Directory. This means:

Account [email protected] in Directory A

is not the same identity record as

Account [email protected] in Directory B.

As a result, you could create a Directory in Stormpath for each of your tenants, and your user Account identities will be 100% separate. With this Directory-per-Tenant approach, your application’s user Accounts are only unique within a tenant (Directory), and users could register for multiple tenants with the same credentials.

Directory-per-Tenant is an advanced data model that offers more flexibility, but at the expense of simplicity. This is the model we use at Stormpath, and it is only recommended for more advanced applications or those with special requirements. 

As a result, we don’t cover the approach in further detail here. If you feel the Directory-per-Tenant approach might be appropriate for your project, and you’d like some advice, just email [email protected]. We are happy to help you model out your user data, whether or not Stormpath is the right option for your application.

We’re Always Here to Help

Whether you’re trying to figure out multi-tenant approaches for your application or have questions about a specific Stormpath API, we’re always here to help. Contact us anytime at [email protected].