This is a continuation of a series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here. The previous articles introduced serverless batch processing with durable functions in Azure Container Instances. This article mentions some of the tenancy considerations in Azure Active Directory.

Azure Active Directory organizes objects like users and applications into groups called tenants. These are security and operational management units from the Azure Active Directory’s point of view. Organizations can set policies on the users pertaining to a tenant and on the applications that the organization owns. Developers can choose to configure applications to be either single-tenant or multi-tenant during the app registration process in the Azure Portal. Single tenants applications are bound to the home tenant.Multi-tenant applications are available to users across tenants. Azure Active Directory uses the audience property to set configure single-tenancy or multi-tenancy.  In the single-tenant mode, all the accounts are in this directory only where the users and guest accounts in the directory can use the application  or API. This is the preferred choice for an audience internal to an organization. In the multi-tenant mode such as for schools and businesses using Microsoft 365, all users and guests can use the application or API even if the accounts are in any Azure AD directory. It is also possible to target an audience that wants to use both work and personal accounts with the multitenant

Setting and this is the preferred choice for the widest possible audience involving Microsoft accounts.

When applications are added to Azure AD, there are two representations: 1. Application Objects – which are the proper definitions of applications, and 2. Service principals which can be considered as representative of applications but there can be multiple representatives for the same application object. Applications can be managed in the Azure Portal through the App registrations experience.

Application objects can be created using application registrations in the Azure portal, creating new applications using Visual Studio and configured to use Azure AD authentication, adding one from the application store, or using Graph API or PowerShell to register or via developer centers. Service principals can be created when users sign into a third-party application integrated with Azure AD or when users sign in to Microsoft online services like Microsoft 365, or by adding an application from the application store, or when an application uses the Azure AD Application Proxy, or if it is configured to be part of Single Sign-On, or programmatically created via the Microsoft Graph API or PowerShell.

 

The best-practices for multi-tenant applications depend on the number of different policies that the IT administrators can set in their tenants. Some practices are applicable generally for multi-tenant applications which include testing the application in a tenant that has conditional access policies configured, following the principle of least user access to ensure that the application only requests permissions it actually needs and providing appropriate names and descriptions for permissions available from the application.

 

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