Identity Management Guidance in Multitenant Applications

Ganesh Chauhan, Technical Support Specialist, Microsoft Azure

The Microsoft Patterns & Practices group has released new guidance on Identity Management for Multitenant Applications in Azure.

One of the first challenges when developing a multitenant app is managing user identities because each user now belongs to a tenant. Users, for example, should be able to sign in using their organizational credentials. Alice, who works at Contoso, signs in as alice@contoso.com.

After Alice signs in, she should only be able to access Contoso data and not data belonging to other organizations. As a result, multitenancy affects authorization policies as well.

Other considerations:

  • Can anyone from any organization use the app? Or does an organization have to sign up first?
  • Do all users have the same access? Or are users assigned roles within the app, such as “admin,” “publisher,” “reader,” and so on?

Azure Active Directory (Azure AD) has some fantastic features that support all of these scenarios. (At the moment, the guidance only applies to tenants in Azure AD.)

This project includes the development of a multitenant application as well as supporting written documentation. Users can create online surveys using the application, which is based on a fictitious company called Tailspin. Because the app is built on ASP.NET Core 1.0 (formerly “ASP.NET 5”), it makes use of the most recent ASP.NET authentication and authorization features.

Please keep in mind that this project is solely concerned with identity management. Other issues, such as data partitioning, are not addressed.

The Surveys app is made up of a web app and a back-end web API. Here’s a high-level overview of the authentication procedure:

Azure AD

Tailspin’s Azure AD directory has the application registered. This enables Azure AD to authenticate users on the application’s behalf. So, when Contoso’s Alice signs into the web app, she is redirected to Azure AD, where she enters her organisational credentials and the web app receives a set of claims about Alice (name, email). The web app also receives an access token, allowing it to access the back-end web API.

Our implementation also includes some intriguing features that address common concerns such as security and performance:

  • Using client assertion instead of OAuth client secrets as a more secure alternative
  • To protect sensitive data such as connection strings, app settings are read from Azure Key Vault.
  • OAuth tokens are cached in a distributed cache that can be shared among web servers.

Authentication, application roles, role-based and resource-based authorization, and authenticating to a back-end Web API are all covered in the documentation.

Professional Labs is the Best Cloud Managed Services Provider USA, for more details contact

Contact Us