This is a follow up to my previous blog re multi-tenant applications using B2C. Here I am describing some changes to the original demo app and comparing use of the classic Azure AD multi-tenant features with supporting multi-tenancy using custom features in B2C.
Here is the list of changes to the demo app:
- The new version of the demo can operate in two modes: using B2C as token issuer or using Azure AD 'Classic' (B2E) as token issuer. In the former mode, it operates as the earlier version using some custom code to provide application multi-tenancy (single B2C tenant, which appears as if segmented into tenants). In the second mode, it uses the standard Azure Multi-tenancy features. Both modes operate from a single deployed service and use url suffix (/b2c or /aad) to distinguish between operating modes.
- The B2C operating mode includes a new IdP: the existing Microsoft Corporate Azure AD tenant. This is to demonstrate what's involved in using AAD 'Classic' as a separate tenant in the context of B2C. I was initially hoping to enable the application as multi-tenant in that (Microsoft Corp) tenant and thus dispense with needing to enable the 'Classic' operating mode altogether but it turned out AAD B2C policies do not allow me to validate issuers against a dynamic, changing list of issuers.
The main differences are as follows:
Using classic AAD multi-tenant features:
- Requires that each customer (clinic in the original blog) has an AAD tenant
- Supports customer's existing access control capabilities: groups, user assignments, conditional access, etc.
- Supports access to customer's other resources (e.g. O365) if consented to by the customer admin
Using AAD B2C:
- Supports customers with standard (OIDC, SAML) IdPs, social and local accounts
- Able to store additional user attributes in the tenant.
- Requires modifications and maintenance of xml policies - not scalable if number of partners with own IdP goes above a couple dozen.
- Requires custom code for handling tenancy, user assignment, policies.