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 identity directory in Azure AD.

Identity directory is the store where a multitenant solution that wants to authenticate and authorize its users or a service, will save and retrieve the identity information. A directory can include authoritative records for each identity, or it might contain references to external identities that are stored in another identity provider’s directory.

When such an identity system is designed for a multitenant solution, we need to consider the types of identity that the tenants and customers might need. These include local identity provider, social identity provider, the tenant’s Azure AD or Microsoft 365 directory, and federation with a tenant’s identity provider.

A local identity provider allows users to self-register with information such as a username, email, identifier, or a rewards card number and a credential such as a password. The identifier and credentials are persisted. 

A social identity provider integrates with social engineering applications so that users can sign in with their profiles from those applications.

Tenants might have their own Azure AD or Microsoft 365 directory and they might want the multi-tenant solution use their directory as the IdP for accessing the multitenant front-end. This is possible only when the solution is built as a multitenant Azure AD application.

Federation with a tenant’s identity provider if they have custom IdP. Federation allows heterogenous IdP to be integrated into a single source of truth for the solution. Federation also enables single sign-on experiences and enables tenants to manage the lifecycle and security policies of their users, independently of the solution. 

A multitenant application does not control how many tenants or the direct ownership of a resource to its tenant. The customer has the complete say in this. They may want to reassign a resource to another tenant. For example, if they decide to join a machine to a different tenant, they need to disconnect from the first tenant and then register again with the new tenant.  The single sign-on (SSO) option for password hash synchronization and pass-through authentication can be used with only one Azure AD tenant. User migration between tenants involves a new credential to be issued at the destination.