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 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.  

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 up to 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. 

The 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 leveraging 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. 

Authorization data can be stored in several places. If the Azure AD is the identity provider, app roles and groups can be leveraged for authorization and the application uses the associated token claims to enforce the authorization rules. A common approach for authorization involves embedding a tenant identifier claim into a token. This enables the application to inspect the claim and verify the tenant access for the user. If role-based access control is available, the role information could also be embedded into the token.  Another option is to store the authorization logic entirely in the application so that there is better customization with fine-grained controls for role-based or resource-level authorization. This calls for the identity system to be made agnostic to tenant-identifiers and roles. Even the tokens do not have tenant identifier claims. A separate registry contains user-to-tenant mappings. The application tier can verify whether the specified user should be allowed to access the data for a specific tenant by looking up that list.