This is a continuation of series of articles on hosting solutions and services on Azure public cloud with the most recent discussion on Multitenancy here This article discusses the Tenant signup and onboarding aspect in Multitenant applications.  

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 nowt 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.   

The signup process is critical to multitenant applications which allows a customer to sign up their organization for the application. It allows an AD administrator to consent for the customer’s entire organization, to use the application. It collects credit card payment or other customer information. It performs any one-time per-tenant setup needed by the application. 

When the application authenticates with the user, the application needs permission to read the user’s profile. The first time the user signs in, a consent page is shown that lists all the permissions that the application needs to perform the authentication. By clicking Accept, the user grants permission to the application.  A consent is granted on a per-user basis but azure AD supports admin consent for the entire organization. The consent page will be suitably worded for the entire organization. 

Several requirements are available for the tenant sign up process. A tenant must sign up before users can sign in, Sign up uses the admin’s consent flow. It adds the user’s tenant to the application database. After the tenant signs-up, it shows an onboarding page. Usually, a multitenant application has an AccountController class where the sign-in action returns a ChallengeResult. This enables the OpenID connect middleware to redirect to the authentication endpoint. The default way is to trigger authentication in ASP.Net core. The Signup action that is different from the signin action also returns a ChallengeResult but it adds state information to the AuthenticationProperties in the ChallengeResult This is relayed to the OpenID Connect state parameter which round trips during the authentication flow from the Azure AD. When the user authenticates with the AzureAD, it gets redirected back to the application. The authentication ticket contains the state. The admin consent flow is triggered by adding a prompt to the query string in the authentication request. This prompt is only needed during sign-up and the regular sign-in should not include it.