Tenancy in Active Directory

Multitenant applications can switch between single tenant deployment mode to multitenant deployment mode. The Active Directory can handle both tenancies and this document discusses how to do that. Single tenant applications must enable sign-in to the home tenant. Multitenant applications are available to users to sign-in to both their home tenant and other tenants.

Public clouds like Azure enable application to be configured for single-tenancy or multi-tenancy via the management portal. The “Accounts in any organizational directory” must be specifically set. The AppID URI of the application must be unique.  Global uniqueness is guaranteed by requiring the AppId URI to have a hostname that matches a verified domain of the Active Directory tenant.

When these applications are developed, there can be a number of challenges from the different policies that can be configured by the administrators.

The best practices for developing sign-in experience on multitenant applications include the following:

1.       The application must be tested in a tenant that has conditional access policies configured.

2.       The principle of least user access must be honored to ensure that the application only requests permission that it needs.

3.       Appropriate names and descriptions for any permissions must be provided. This helps users and administrators know what they are agreeing to before they give consent.

When the sign-ins are configured to be accepted from any Active Directory tenant, it makes the application multi-tenant. If the application is using an existing proprietary account system or from other cloud providers, Active Directory sign-in can still be added via OAuth2, OpenID connect, or SAML integration if the application adds a published UI control on their sign-in page.

In a single-tenant application, the sign-in requests are sent to the tenant’s sign-in endpoint. In the multitenant application, the originating tenant from which the user is attempting to sign-in is not known. Instead, requests are sent to an endpoint that multiplexes across all the Azure AD tenants. When the Microsoft’s identity platform receives a request on the /common endpoint, it signs the user in and discovers the tenant she belongs to and sets this value in the issuer field in the token response to the application. The application can read the issuer field in the token response and take it to correspond to the user’s tenant. The application must handle the validation of the token before reading this field from the multiplexer. There could also be multiple issuer values. Each public cloud AD tenant has a unique issuer value of the form of a URI containing a GUID. A single tenant application can validate the tenant by matching the GUID in the response, but a multitenant application only receives a templatized URI from the multiplexer and is unable to validate it this way. It must maintain a registry of valid tenants and check the issuer value or the tid claim value in the token. It can also choose to admit based on userId registry and ignore the tenant Id altogether.