Identity Management in Multitenant applications:

Tenants and their users are recognized by their identity in a multi-tenant application. If we hide the complexity of identity store behind a well-known product such as Azure AD, the best practices for authentication and identity management stand out.

Every user belongs to a tenant. This is the foremost challenge to address. A user signs in with her organizational credentials. She may have access to the data from her organization but not to the data from other tenants. She can register with the multitenant application/service and then after her account is created, she can assign roles to other members.

Identity and access management provide built-in features to support all these scenarios. So, they simplify the logic that the multi-tenant application must execute to log them in. The mapping of these functionalities to the Software-as-a-service is now discussed. 

Let us say there are two users alice@contoso.com and bob@fabrikam.com who want to login to a multitenant SaaS application. Since they belong to different tenants, the application must map the user to the right tenant. Alice cannot have access to Fabrikam data in this case.

Azure AD can handle sign-in and authentication of different users and the multitenant application is the same physical instance that recognizes and isolates the tenants to whom the users belong. A tenant can be considered a group of users in a B2B and has one-to-one mapping with a user in a B2C scenario. The application itself may have several physical resources such as VMs or storage but each tenant gets its own logical instance of an application. Application data is shared among the users within a tenant but not with other tenants. In a single-tenant architecture, each tenant gets dedicated physical resources and new instances of the app can be created for tenants by scaling out the number of instances.

This approach of horizontal scaling or scaling out is best possible in a web application. More traffic can be handled when there are more server VMs, or containers and they are put behind a load balancer. Each VM or container runs a separate instance of the web application.  Requests are routed to any instance. The whole instance functions as a single logical instance to the users. Scaling in or out does not affect the users in this case. If one instance goes down, it should not affect any tenant. 

During authentication, such as when a user accesses a resource, the application must determine the user’s tenant. If the tenant is already onboarded to the application, then such a user does not need to create a profile. Users within an organization are part of the same tenant.  Any indicators for the tenancy that comes from the user such as the domain name of the email address used to login cannot be trusted. The identity store must be used to resolve the tenant. 

During the authorization, the tenant determination for the identity involved must be repeated.  Users must be assigned roles to access a resource. The role-based access control relies on the role assignments from the tenant administrator or the user if the resource is owned by the user. The role assignments are not made by the tenant provider.

When Azure AD is used for identity management, the customers store their user profiles in the Azure AD even if they were an Office 365 tenant or a Dynamics CRM tenant. Once the profiles are in the AD, the multi-tenant application can look up. If a customer with on-premises Active Directory wants to use the application, the AD connector can sync the data from on-premises to the cloud. This identity federation empowers the Azure AD to be a single store for cloud applications to use. 

Data partitioning and per-tenant configuration can be decided by the multi-tenant application independent of the identity and access management solution.

Reference: This document is a continuation in a series of articles regarding multi-tenancy with the most recent article linked here