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 closure on Service Fabric discussion as per the summary here. This article discusses the claims-based identities in the new series on 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.  

Claims-based identities in Azure AD involves sending an ID access token that contains a set of claims about the user. A claim is simply a piece of information, expressed as a key-value pair. For example, the email associated with the user is a claim. Azure AD authenticates the user and creates the claim. The claims are trusted because the issuer is trusted. The issuer is also referred to as the Identity Provider (IDP) 

Using this technique, an application is no longer responsible for the following: 1) authenticating users 2) storing user accounts and passwords, 3) calling membership providers like enterprise directories to lookup user information 4) integrating with identity systems from other organizations and 5) providing implementations for several protocols to be compliant with industry standards and business practice. All the identity related decisions are based on claims supplied by the user.  An identity is a set of attributes that describe a principal. A claim is a piece of identity information. The more slices of information an application receives, the more complete the pie representing the individual.  Instead of the application looking up the identity, it merely serializes them to the external system. A security token is a serialized set of claims that is digitally signed by the issuing authority. It gives the assurance that the user did not make up the claim. An application might receive the claim via the security header of the SOAP envelope of the service. A browser-based web application arrives through an HTTP POST from the user’s browser which may later be cached in a cookie if a session is enabled. The manner might vary depending on the clients and the medium but the claim can be generalized with a token.  Open standards including some well-known frameworks are great at creating and reading security tokens. A security token service is the plumbing that builds, signs and issues security tokens. It might implement several protocols for creating and reading security tokens but that is hidden from the application.