In the last post, we have seen how to design multi-tenant solution and what all factors influence design decisions. One of the questions I received on that post – what about authentication and authorization in multi-tenant scenario?

To understand authentication and authorization in a multi-tenant scenario, let’s refer back the example of Apartment Society, where each apartment is classified as single tenant within an Apartment Society. Each apartment may have multiple residents, which can be classified as users and all are authenticated before entering the apartment society. Each one of them can share common resources of apartment society. But when they have to enter any apartment, they are authorized first. That means, after authorization they can only enter their own apartment, not into any other apartment. So, in short, at the time of entering an apartment society, authentication occurs, and at the time of entering an apartment, authorization occurs.

Now for multi-tenant solution, this authentication and authorization experience can vary. That depends on, at what time user is selecting its tenant/organization to which they belong to. This experience can be categories into three major categories,

• Tenant selection before authentication – In this case, user will be asked to provide/select tenant name along with authentication details. System will process authorization, along with authentication for this type of user.
• Tenant selection after authentication – In this case, user will be authenticated first. After that user will be prompted to provide/select tenant name, based on that he/she will be authorized.

• Automatic tenant selection based on domain – In this case, during the time of authentication, system will identify the user’s sub-domain or company’s organization from his/her email ID and based on that information user will be automatically authorized.

Now the question comes, is there a simple way to implement this authentication and authorization. Answer is YES, within Azure, you have two options – Azure AD B2B and Azure AD B2C.

• Azure AD B2B is for scenario, where you would like to share organization resources with external users so they can collaborate. https://docs.microsoft.com/en-us/azure/active-directory/b2b/what-is-b2b
• Azure AD B2C is primarily for customer-facing applications. Azure AD B2C can be leveraged as full-featured identity system for your application, where different tenant/organization identities can be supported.

Sign-in journey using Azure AD B2C

Following is an example of sign-in journey using Azure AD B2C,

• Step 1 – user select identify provider
• Step 2 – user provides username and password
• Step 3 – leverage Azure AD B2C for authentication, which internally connects to multiple identity providers. Please refer tutorial about how to add identity providers – https://docs.microsoft.com/en-us/azure/active-directory-b2c/tutorial-add-identity-providers
• Step 4 – Authorize user based on tenant, and additional attributes collated from any CRM system.
• Step 5 – Issue Azure AD B2C token to the calling application
• Step 6 – Calling application receives token, parses claims and accordingly process access to the user.

Recently I was having a conversation regarding multi-tenancy, and one of the responses I got – our application already supports multiple users, so it’s already a multi-tenant. Do multiple users mean multi-tenant – is that correct?

Before we even go further and explore multi-tenancy, lets understand difference between a user and a tenant.

• User – User is smallest unit of classification. User can be independent or can belong to a role or a tenant. Simplest way to identify a user – user will have its own username and password to login into the system.
• Role – Role is classification within a tenant and multiple users can belong to a role. E.g. within a system, a group of users may belong to an administrator role or sales role, etc. One role may overlap over another role, but a role can’t be a subset of another role.
• Tenant – Tenant is the largest classification. Tenant is generally used to define a department, or an enterprise, which enforces their own policies or rules within a system. Each tenant will consist of different set of users. User is not shared across a tenant.

Apartment Society is a perfect example of a multi-tenancy. Apartment Society has centralized administration for security (CCTV, security at entrance, etc), electricity, water, and other facilities. These facilities are governed by the apartment association and shared by tenants. One apartment can be classified as one tenant, for whom the individual electricity/water bill is generated. But each apartment may have multiple users, i.e. family members staying within an apartment. And what is a benefit of an apartment – it provides security, privacy to a tenant, even if they are using shared resources of apartment society like electricity, water, parking etc.

So, what is Multi-tenancy with respect to Software?

When a single application is shared by multiple tenants (i.e. organizations or departments) is termed as multi-tenant application, considering each tenant is oblivious of another tenant. Multi-tenant application should be smart enough to have partitioning of data, compute and user experience based on each tenant.

Benefits of multi-tenancy

1. Reduction of operational cost – as shared infrastructure is leveraged by multiple tenants.
2. Centralized management – as shared infrastructure needs to be managed, rather than multiple infrastructures for each tenant.
3. Reduces turn around time to on-board new tenant.

Things to be considered carefully while designing multi-tenant solution

1. Data Privacy – strict authentication and authorization required, so that customers should only access their own data.
2. Serviceability and Maintainability – single update to the application will affect many different tenants, so any update must be planned carefully.

What factors influence multi-tenant architecture?

Before we define a multi-tenant architecture, lets look at what factors will influence architecture patterns for multi-tenancy,

1. Views – tenant can define styling of the application
2. Business Rules – tenant can define their own business rules and logic
3. Data Schema – tenant can define their own database schema for the application
4. Users and Groups – tenant can define their own rules to achieve data/system level access controls
5. User or System Load – each tenant may have different user-load requirements. E.g. Tenant-A has huge user base, and in comparison, Tenant-B & Tenant-C combined has a small user base.

Type of design patterns to implement Multi-tenancy

Multi-tenancy with a single multi-tenant database

This is the simplest form of multi-tenancy. It consists of single instance of app instance (both UI and business layers), along with single database shared across multiple tenants. Usually tenant data is segregated within the database using tenant key/ID.

Multi-tenancy with single database per tenant

Second form of multi-tenancy is – single instance of app instances (both UI and business layers), but database is segregated for each tenant. Cost will be higher than the first option, but operation complexity will reduce due to individual databases, and will make it easy to manage data schema changes for each tenant.

One of the solutions to implement this pattern is through Azure SQL Database Elastic Pool feature – https://docs.microsoft.com/en-us/azure/sql-database/sql-database-elastic-pool

Multi-tenancy with single-tenant business compute instances with single database per tenant

Third form of multi-tenancy is – single instance of UI app instance, but business compute layer and database are segregated for each tenant. Cost will increase more than the second option, but operation complexity will reduce due to individual databases and easy to manage business compute instances for each tenant. Will make it easy to implement and deploy business rules for each tenant.

With adoption of containerization and docker technology, it becomes easier to segregate compute instances, and even than manage them as one unit. Examples are Azure Service Fabrics and Kubernetes. Azure Service Fabric and Kubernetes are distributed systems platform that makes it easy to package, deploy, and manage scalable and reliable micro-services and containers.

Multi-tenancy with single tenant compute instances with single database per tenant

Fourth form of multi-tenancy is – all three layers, UI app instance, business compute layer and database are segregated for each tenant. Cost will be highest for this option, but will provide complete segregation of security, privacy, compute and data for each tenant.

Hybrid Approach for Multi-tenancy

We looked at four different patterns to implement multi-tenancy. There is another factor that influence a lot in selection of patterns, i.e. user/system load for a tenant. Suppose user load for Tenant-A is so huge that we can’t share its instances with another other tenant. But user load for Tenant-B & Tenant-C can be shared within a single instance.  So, for these scenarios, you can consider hybrid approach, i.e. mix and match option 1 to 4. Example – for Tenant-A, go for segregated compute and database instances, but for Tenant-B and Tenant-C, you can go for shared compute instances.

So in end, multi-tenant architecture will help you serve everyone, from small customer to large enterprise, using shared resources, reduced cost and brings operational efficiency.