The 'regular' Azure AD has build-in support for multi-tenant applications. In that case, a user from any Azure AD tenant can sign in to an application registered in another tenant. The application can then use the user's security context to give the user a view of data that is specific to that tenant.
The goal of this article is to explore providing similar support using Azure AD B2C with one major difference: instead of using multiple Azure AD tenants, we will use a single B2C tenant and allow all registered users (using social ids or local user ids) to access the application with a 'tenant' context of their choice. For example, consider a SaaS application for small doctor clinics. The doctors are not employed by any single clinic. They use their own social ids (live, gmail, etc.) to authenticate and may in fact work for several clinics at different times. In this case, each clinic is a tenant. In B2C terms, where an individual has a single social or local id, we will need to allow each doctor to use the application within the context of a single clinic at any given time but allow them to change that context over time, for example to record their work against different clinics at different times.
To support this, AAD B2C needs to support three user scenarios:
- A B2C user wants to create/establish a new tenant (clinic) in the application.
- A B2C user wants to become a registered user of a tenant (doctor joins a clinic).
- A B2C user already registered as per (2) above, wants to use the application within the context of a particular tenant (clinic).
This demo application illustrates how the above can be implemented. The application exposes two separate sign-in controls (hyperlinks): one for users who want to create a new tenant (1 above) and another for those who want to use an existing tenant (2 and 3). These could also be exposed as two separate applications: one for taking on new tenants and another for regular use of existing tenants. If a user signs-in using the first control, the application will take the user though logic needed to create a new tenant. At the end of the process, the user will be registered as an administrator of that tenant. Once a tenant is created, the administrator can create redemption codes (secrets), which can then be distributed to potential other users to enable them to sign-up into this tenant. Once a user has sign-up for a tenant, subsequent sign-ins to the system will either allow the user to access that tenant or give the user a list of tenants they can operate within (if they signed up for more than one). From then onwards, a user operates within the application as if it was dedicated to the selected tenant.
Currently, all this logic is implemented as part of the application and kept in a local SQL database. The next step is to move as much of it as possible into the B2C custom policies.
