Setting up Web App Multitenant Azure AD Sample

Tuesday, August 4, 2015

Multitenancy in Azure AD is a very cool concept with the Consent Framework if you're and ISV or a Service Provider building a cloud service that you're looking to monetize.

When you're building a service, you inevitably have to control access to your services with user identities. But that brings on the headaches and extra cost of identity management:

How do I turn off access when a registered user leaves my customer's company so I can turn off access?
How much does your helpdesk provider charges for a simple password reset call?

Multitenancy in Azure AD is a way around that. It also allows your customer to take full advantage of their investments into managing corporate identities for accessing Office 365 or advanced security features like Advanced Threat Analytics or Privileged Identity Management. It also doesn't cost you, the service provider anything, it's up to your customer to decide which Azure AD capabilities they require, what they already have and how much they want to pay.

You can start exploring multi tenancy in Azure with the WebApp-MultiTenant-OpenIdConnect-DotNet sample on github.

Simply:

Clone the repo
Follow the configuration steps for the App
Configure a connection string the Entity Framework data store (see below)
Publish to an Azure Website (or publish using Visual Studio 2015)

Configuring the Entity Framework data store is super simple, too. Since you're hosting the app in Azure it makes sense to use a Azure SQL Database as the data store for your app. A Basic Edition will do just fine since this is just a sample app you're using to explore the functionality.

Once you created the database, you add a connection string setting to the web.config:

<configuration>

<connectionStrings>

   <add name="TodoListWebAppContext"
     connectionString="Server=tcp:<yourdbserver>.database.windows.net,1433;
         Database=<yourdatabase>;
         User ID=<adminuser>@<yourserver>;
         Password=<youradminpassword>;
         Trusted_Connection=False;
         Encrypt=True;
         Connection Timeout=30;"

providerName="System.Data.SqlClient"/>

</connectionStrings>

</configuration>

That's all you need to get going with the sample.

There is one more thing to note when you Sign Up, i.e. you go through the scenario where your customer's provides consent to provision the app into their own Azure AD tenant to allow their users to access the app.

You trigger the consent code path by checking the little check box on the Sign Up screen. This indicates that you're signing in with the admin account of another Azure AD directory. This can be another directory within the same subscription to simplify things for testing purposes, or a directory in an entirely different tenant to simulate the real scenario of your customer signing up.

The app will redirect you to the Azure AD sign in page. When you signed in with an account that has the Global Administrator or Service Administrator role assigned, you'll also get the consent page as part of the sign in flow.

Now when you take a look at the Applications my company uses in the directory you see that the app has been provisioned:

Be sure you're signing in with a user account that's homed in that directory, i.e. NOT the Microsoft ID you may be using to sign into the Azure Management portal. When you do, you get AADSTS50020: User account '<user>@live.com' from external identity provider 'live.com' is not supported for application <Client ID>'. The account needs to be added as an external user in the tenant. Please sign out and sign in again with an Azure Active Directory user account.

No Comments