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

When you're building a multitenant app, one of the first challenges is managing user identities, because now every user belongs to a tenant.  For example, users should be able to sign in with their organizational credentials. Alice, who works at Contoso, signs in as alice@contoso.com.

After Alice signs in, she should have access to Contoso data — and not have access to data that belongs to other organizations. So multitenancy affects authorization policies as well.

Other considerations:

• Can anyone from any organization sign into the app? Or does an organization need to sign up first?
• Does every user have the same privileges? Or do users get assigned roles within the app, such as “admin,” “publisher,” “reader,” and so on.

Azure Active Directory (Azure AD) has some great features that support all of these scenarios. (The guidance currently only supports tenants in Azure AD.)

This project includes an implementation of a multitenant application, plus supporting written guidance. The application, based on a fictitious company called Tailspin, allows users to create online surveys. The app is built on ASP.NET Core 1.0 (formerly “ASP.NET 5”), so it uses the latest authentication and authorization features for ASP.NET.

Note: This project is focused specifically on identity management. It doesn't look at other issues such as data partitioning.

The Surveys application consists of a web app and a back-end web API. Here’s a very high-level view of the authentication process:

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

Our implementation also has some interesting features that address cross-cutting concerns like security and performance:  

• Using client assertion as a more secure alternative to OAuth client secrets
• Reading app settings from Azure Key Vault, to protect sensitive data, like connection strings
• Caching OAuth tokens in a distributed cache, which can be shared among web servers

The guidance covers a range of topics, including authentication, application roles, role-based and resource-based authorization, and authenticating to a back-end Web API.