Software-as-a-Service Part 1 (Identity-as-a-Service)

Developer Support

App Dev Manager, Keith Anderson explores aspects and patterns of building solutions under a Software-as-a-Service model.

I often get asked by customers who are independent software vendors (ISVs) for a prescription for writing and providing software as a service.  Pointing to Office 365 as a shining example of successful SaaS is woefully insufficient.  Providing a prescription of steps to create and provide SaaS is an overwhelming endeavor, destined to sprawl and quickly become unwieldly.  Yet companies need exactly this as they transition to the cloud.

To answer this need, we identify some patterns and group them into related pillars.  My intention in this series of posts is to showcase various applications demonstrating different aspects and patterns of Software-as-a-Service (SaaS) models.

The first post will showcase the identity-as-a-service (IDaaS) pillar using Azure Active directory and OAuth2 + Open ID Connect modern authentication protocols and how this supports multi-tenant apps in Azure.

These samples and tutorials are open-source and available as part of the Microsoft Azure documentation.  I would like to call out and thank Danny Strockis, an Identity Services Program Manager at Microsoft.

  • POC 1 – Multi-tenant Identity-as-a-Service
    • Source code
    • Demo and walkthrough
    • Link to documentation

POC 1 – Multi-tenant Identity-as-a-Service

You cannot explore the topic of SaaS architectures long without touching on identity and tenancy models. Generally speaking, a tenant is an entity occupying a property.  The tenant metaphor works better for cloud computing when you think of an office building full of businesses leasing space, than say, a landlord renting an apartment to individuals.  A tenant in Azure Active Directory represents an organization and technically is nothing more or less than an instance of Azure Active Directory (AAD).

Therefore, a multi-tenant application in the context of AAD is simply one that supports more than one instance of AAD.

This is a narrow definition of muti-tenancy, and more generally, a multi-tenant application is one that supports more than one organization, regardless of the identity mechanism, but it is important to realize that context matters when discussing terms.  This first POC explores the narrow AAD definition of multi-tenancy and later POCs explore a more general definition in terms of customer data.

Build a multi-tenant SaaS web application using Azure AD & OpenID Connect

The TodoListWebApp is a sample application that shows how to build and register a multi-tenant application with Azure Active Directory, so that users from any AAD tenant can sign in with their own credentials.  It leverages Azure AD for IDaaS, and also demonstrates how this can be used in hybrid scenarios.  This application can be deployed anywhere and leverage Azure AD to manage access.

Register the app in AAD

The complete setup instructions in the Azure documentation linked at the end of this post go through everything step by step, so I will not reproduce them here.  I will point out a couple of details worth noting.  We need to register an application in AAD so that users of that directory can authenticate through the service.  You will need to specify the redirect URL so Azure can send you back to your homepage once the authentication flow has taken place.  You will also need to specify the logout URL so the session can be terminated.

From a tenancy perspective, the interesting bit about this is the flag you can set at the bottom, specifying Multi-tenanted, Yes or No.


If ‘Yes’ is specified, users from other instances of AAD can authenticate through this service and log in to your application.  If ‘No’ is specified, only users registered in your AAD can do so.

AAD Authorization needs to know where to return tokens containing claims to your application.  For this reason, you need to specify these end points in the Reply URLs.


Another interesting point to note is that it doesn’t actually matter where the application is deployed, as long as it can access Azure and as long as AAD can call back to your home site, the application itself can be hosted on prem, in Azure, or some other cloud.

The following content was structured for demos and discussion.  You can follow these steps as shown or the tutorial steps in the documentation.  If you wish to engage Premier Developer for added context, please contact your local ADM or TAM, or if you need a Premier contract, reach out to your Microsoft representative for information.  You can also consult for information on Premier services.

Before performing these steps, make sure to sign out of your browsers if you are signed in with your Microsoft account.

Create a new App Registration

  1. Create a new App Registration in the Azure Portal

  2. Open Settings and Add Properties

  3. Enter Reply URLs

  4. Add the Microsoft Graph API

    • Select the Sign in and read User Profile permission

  5. Provision a Secret Key

  6. Open the App Manifest and discuss App Specific Roles

    • Add an App Specific Role

[{      "allowedMemberTypes": [



“displayName”: ” Export/Import”,

“id”: “d31fca6f-6cbe-408a-9387-8ac53b77d548”,

“isEnabled”: true,

“description”: “App Specific – Export/Import”,

“value”: “ImportExportAdmin”


Identity as a Service (IDaaS)

Azure Active Directory is a fully managed service to provide authentication and authorization to your applications.  It is highly integrated with other Azure services, but can be used as a stand-alone service as well, to provide AuthN/AuthZ to your applications on prem or in some other cloud.

Log in with same-domain account as registered application

  1. Create a new user in the Azure Portal

    • Show Applications assignment is empty

  2. Sign in with same domain account

    • Show Applications assignment is now populated

  3. Demo the app with a same-domain user

  4. Debug the app and show the claims in the ClaimsPrincipal during any action

  5. Assign the App Specific role to the user and show how it is now part of the claims

Log in with domain account different from registered application

  1. Log in with user from cross-domain account

    • Show error

  2. Toggle Multi-tenanted flag to ‘Yes’ and Log in with cross-domain account {There will be a slight delay while this takes effect, even after the Portal indicates the change was made}

    • Show success

  3. Demo the app with a cross-domain user

Create and Log in with Guest B2B account

  1. Toggle Multi-tenanted flag to ‘No’

  2. Create a Guest user in same domain as registered application, inviting a cross-domain user. {This takes time.  An email initiation will be sent.  The user has to accept the invitation.}

    • Show Applications assignment is empty

  3. Sign out after accepting invitation.

  4. Sign up in the application with B2B user.

    • Show Applications assignment is now populated

  5. Demo the app with a B2B user

Source code and Complete Setup Instructions

Here is a link to the complete setup instructions and a link to the git repository housing the source code:

Setup Instructions:

Git Repository:

Other Resources: Developer’s Guide to AAD

App Roles –


In this post, we explored the identity pillar of developing and operationalizing software as a service and we explored multi-tenancy with respect to identity using Azure Active Directory Identity as a Service.

Premier Support for Developers provides strategic technology guidance, critical support coverage, and a range of essential services to help teams optimize development lifecycles and improve software quality. Contact your Application Development Manager (ADM) or email us to learn more about what we can do for you.


Discussion is closed.

Feedback usabilla icon