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.  

The code sample appear like this: 

[AllowAnonymous] 

public IActionResult SignIn() 

{ 

    return new ChallengeResult( 

        OpenIdConnectDefaults.AuthenticationScheme, 

        new AuthenticationProperties 

        { 

            IsPersistent = true, 

            RedirectUri = Url.Action("SignInCallback", "Account") 

        }); 

} 
[AllowAnonymous] 

public IActionResult SignUp() 

{ 

    var state = new Dictionary<string, string> { { "signup", "true" }}; 

    return new ChallengeResult( 

        OpenIdConnectDefaults.AuthenticationScheme, 

        new AuthenticationProperties(state) 

        { 

            RedirectUri = Url.Action(nameof(SignUpCallback), "Account") 

        }); 

} 

Since many users can map to the same tenant, the application database could include a tenants table with id and issuerValue attributes and a user table with Id, tenantId, ObjectId, DisplayName, and Email properties for taking the following actions. If the tenant’s issuer value is not in the database, the tenant has not signed up. If the user is signing up, the tenant is added to the database and the authenticated user is added to the corresponding table. Otherwise, the normal signin process is completed. 

Application roles are used to assign permissions to the users. It defines the following roles: Administrator, Creator and Reader. These roles imply permissions during the authorizations. There are three main options to assign roles: Azure AD App Roles, Azure AD security groups, Application Role Manager