Building a multi-tenant Active Directory web app

Decorating your SaaS offering with multi-tenant Single-Sign-On (SSO) can be a huge benefit, allowing your enterprise users to switch between their Office 365 home and your web app seamlessly.

While you can find a few resources that help you build just that, most of them are in the form of a project template or a complete solution on Github. Like this one (TodoListWebApp). For my projects I prefer to keep them clean, and write as much code by myself; avoiding templates that carry more capabilities than I need, or even carry out operations that I don’t completely understand.

This tutorial aims at quickly building a boilerplate multi-tenant active directory authenticated web app implemented using Open ID Connect with OWIN.

STEP I : Register an Azure AD application

Start with registering an application in your organization’s Active Directory. You can follow the  in-detail MSDN guide here (Manually register Azure AD application).

  1. Go to Active Directory in Azure Portal. Navigate to the Applications tab.
  2. Select Add in application my organization is developing.
  3. Give your application a name. This name will be visible to administrators while approving your application for use in their tenant.
  4. Select Web application and/or Web API. Hit next.
  5. Enter a sign-on URL that your user’s will use to sign-in. e.g: https://contoso.com/login
  6. The App ID URI can be same as the domain or URL of your sign-on URL, but you need to make sure that you use a domain registered in your Active Directory. If you do not have custom domains, your App ID URI should look like this. {app-name}.{tenant-name}.onmicrosoft.com.
  7. Hit next, and you AD app will be created.
  8. Navigate to your registered AD app in the applications list.
  9. In the Configure tab set Application is multi-tenant to Yes.
  10. Save changes.

With this your AD app is configured. We will come back to the configuration once our web app code is in shape.

STEP II : Initial project setup

Open Visual Studio, and create a ASP.net Web Application. On the next window, change authentication to No Authentication. We will setup our own authentication flow using Owin and Open ID connect.

Once the project is created, install the following nuget packages that will be required later.

  • Microsoft.Owin
  • Microsoft.Owin.Security.Cookies
  • Microsoft.Owin.Host.SystemWeb
  • Microsoft.Owin.Security.OpenIdConnect
  • Microsoft.IdentityModel.Clients.ActiveDirectory

STEP III : Setup auth on Application Startup

Create a partial class called Startup with the following code.

Next, create a new class file under App_Start named Startup.Auth.cs. Implement the ConfigureAuth method here as shown below. Splitting the Startup class in this fashion makes it easier to maintain.

The Open ID Connect OWIN security component is used in Startup.Auth and our own logic handles the notifications triggered at each step.

STEP IV : Getting Admin consent for your web app

For a 3rd party multi-tenant application, the tenant admin is required to approve the application for use in his AD. Once the authorization and authentication logic is in place, we need to implement a way to gain admin consent.

Create a SetupController that will handle redirect to URL with “prompt=admin_consent“. This URL will work only for Tenant Admins.

Once the admin approves the 3rd party app, he will be redirected to /Setup/Process along with an auth code. We process the auth code in the Process action.

You will still need to implement a view for the Index action that can sent the post request to the Index action.

STEP V : Final configuration

Once the above code is in place, make sure the web.config has the correct credentials from the AD app config. Copy the Client ID, and generate a new Client Secret and add to web.config in the follow fashion under <appsettings>.

<add key=”ida:ClientID” value=”{client-id-from-application-config}” />
<add key=”ida:Password” value=”{client-secret-from-application-config} ” />

While you are on the application configuration tab, add a new Redirect URL for /Setup/Process. e.g: https://localhost:43303/Setup/Process

With that done, you can run your app on a new AD tenant and follow the authflow to approve your app through a tenant admin account. You can decorate your controllers/actions with the [Authorize] attribute and users will prompted to login if they haven’t already.

Note: In this tutorial I have not used TokenCache notifications to keep this solution focused on auth flow. I will be focusing on TokenCache in a separate post.

The full solution is available for on github here.

2 Comments

Leave a Reply