Identity Management in Multitenant applications: 

This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Service Fabric as per the summary here. This article discusses the architectural approaches for securing a multitenant application. 

Tenants and their users are recognized by their identity in a multi-tenant application. Every user belongs to a tenant. 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. 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.

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. 

On-premises AD can be federated with the Azure AD with the help of a connector. Security can be further improved by enabling private connectivity to the multitenant application. Security can also be improved for connectivity between the application and other Azure PaaS services over Azure Private Link. These connections might include other web applications, Azure SQL databases, Azure Storage, Azure KeyVault, and all the services that support Azure private endpoints for inbound connectivity. Azure Private Link sets up a private endpoint for the PaaS services, web applications, Azure SQL Database, Azure Storage Account, and the Azure KeyVault. The On-premises network and the Azure virtual network can be connected via a Site-to-Site (S2S) VPN or Azure ExpressRoute private peering. The on-premises network and the remote Azure virtual network are connected via private peering.  An on-premises network that already has a domain name system solution in place and use a conditional forwarder to forward DNS traffic to Azure DNS. This forwarder resolves all the DNS queries via a server-level forwarder to the Azure provided DNS service. Azure Firewall and Virtual network configurations are still required.  The application rules for allowing communication between the VNet Integratiion subnets and the private endpoints of Paas Resources are written with the help of the Azure Firewall.

An alternative approach for private connectivity is to use App Service Environment to host the multitenant application in an isolated environment. For some other Azure Services, there is no alternative to using private endpoints for highly secure and private connections from WebApplications.

Application routing can be configured to route either all the traffic or only private traffic into the virtual network. The former is used to block all traffic to public ip addresses. A network security group can also be used to block outbound traffic to resources in the virtual network.