This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the architectural approaches for Identity in multitenant solutions.     

Identity services like storage services are hetereogenous in their constitution. Identity systems vary in flavor and size depending on the methods of authentication and authorization that they support. Not all Identity systems have the same capabilities. Multitenant solutions introduce sharing which brings a higher density of tenants to infrastructure and reduce the operational cost and management. Unlike compute or storage, isolation model can be as granular as the users. Services that limit the number of users supported in a single multi-tenant instance must all rely on Azure Active Directory. Different users even in the same solution might have different throughput requirements. Throughput refers to the total bytes transferred in unit time and can be affected by both the number of messages as well as the size of messages. 

When these Identity resources are shared, their isolation model, impact to scaling performance, state management and security of the Identity resources become complex. These key decisions for planning a multitenant Identity solution are discussed below.    

Scaling resources helps meet the changing demand from the growing number of tenants and the increase in the amount of traffic. We might need to increase the capacity of the resources to maintain an acceptable performance rate. For example, if a single AAD instance is provisioned for all the tenants and the user belongs to more than 500 Azure AD tenants or creates more than 200 directories, the AAD instance will reject the application’s requests and all the tenants will be impacted. There are many service limits and quotas to be considered.  There cannot be more than 5000 domain names. If the domains are federated with an on-premises Active Directory, there cannot be more than 2500 domain names in each tenant. A maximum of 50,000 Azure AD resources can be created in a single tenant by users of the AAD free edition. If there is at least one verified domain, the default AD service quota is extended to 300,000 Azure AD resources. A non-admin can create no more than 250 Azure AD resources. A maximum of  100 users and service principals can be the owners of a single application. There can be upto a maximum of 1500 app role assignments for a single user, group or service principal. Azure AD supports group nesting and group membership claims. A single application proxy is allowed a maximum of 500 transactions per second.

Authentication process involves several aspects such as Federation, Single sign-on and sign-in risk evaluation, Impersonation etc. Authorization can be done either in the identity provider or in the application. It might involve adding tenant identity and role information to tokens or leverage application based authorization. Azure AD or Azure AD B2C can be used with the multitenant application.

Federation is particularly helpful to special logins from diverse identity providers such as those from social engineering applications and Tenant-specific directories such that the application’s IDP can be used to federate with the Tenant’s own identity providers. Single sign-on experiences enable users to switch between applications seamlessly without requiring reauthentication. A multi-tenant application may choose to provide single-sign on for users who are part of different tenants so that work with isolated data of different tenants without requiring to reauthenticate. Multi-factor authentications that mitigate Sign-in risks might be applied conditionally to participating tenants who might have different risk policies. It can also depend on the multitenant solution provider that offers restrictive sign-in policies as part of a higher pricing tier of their service. Impersonation is user-specific and enables one user to assume the identity of another user without requiring their credentials. This is usually an advanced technique fraught with danger and difficulty to implement and control. In some scenarios, impersonation is a requirement and the multitenant solution provider must log both identities for troubleshooting.

Reference: Multitenancy: https://1drv.ms/w/s!Ashlm-Nw-wnWhLMfc6pdJbQZ6XiPWA?e=fBoKcN