Identity Management in Multitenant applications:   

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

Identity and access management provide built-in features to support all these scenarios. So, they simplify the logic that the multi-tenant application must execute to log them in. Let us say there are two users alice@contoso.com and bob@fabrikam.com who want to login to a multitenant SaaS application. Since they belong to different tenants, the application must map the user to the right tenant. Alice cannot have access to Fabrikam data in this case.   

Azure AD can handle sign-in and authentication of different users and the multitenant application is the same physical instance that recognizes and isolates the tenants to whom the users belong.  

During authentication, such as when a user accesses a resource, the application must determine the user’s tenant. If the tenant is already onboarded to the application, then such a user does not need to create a profile. Users within an organization are part of the same tenant.  Any indicators for the tenancy that comes from the user such as the domain name of the email address used to login cannot be trusted. The identity store must be used to resolve the tenant.    

During the authorization, the tenant determination for the identity involved must be repeated.  Users must be assigned roles to access a resource. The role-based access control relies on the role assignments from the tenant administrator or the user if the resource is owned by the user. The role assignments are not made by the tenant provider.   

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