Smarter ideas worth writing about.

Broaden Your Software's Reach - Part 2

Tags: Cloud Enablement , Azure

 

Part 2: Harnessing the Power of Active Directory in the Cloud

So it has been quite a while since I posted Part 1 of this article.  A lot has changed in the Windows Azure ecosystem since then, in particular the release to market of the Windows Azure Active Directory (WAAD) service.  In this post I will show you how WAAD can put you on the fast-track to a SaaS application with remarkably few steps.


User Identity

Active Directory (AD) is very familiar to most of us as the means of managing users in a Windows network domain.  Microsoft has taken this same technology and moved it into the cloud.

Users in WAAD are mostly self-explanatory, but one quick note worth mentioning is the Azure offering doesn’t quite allow the level of configuration that is available for an on-premises AD.  For example, in WAAD you only have the ability to designate a user account with the "User" or "Global Administrator" roles.  WAAD handles the user authentication on your behalf and identifies the user to the application via a set of authorization claims.  This authentication dance can be achieved using standard protocols such as WS-Federation, OAuth 2, or SAML-P, all supported by WAAD. 

Taking WS-Federation for instance, authentication takes the following steps:

  1. When a user first sends a request to your application the Windows Identity Foundation (WIF) will intercept the request and examine it for a valid token.  If the token is missing, the user is given a redirect response to go to a WAAD endpoint for login.
  2. The user accesses the WAAD login page and enters credentials matching a valid user.
  3. A security token is passed back to the user’s browser along with another redirect response back into the application
  4. The application receives the security token passed by the redirect and WIF extracts the authorization claims.
Figure 1: The WAAD WS-Federation dance.

The application is then free to use the authorization claims to give appropriate access to the user who is now known to the application. 

A significant capability of WAAD is that you can synchronize your on-premises AD into the cloud.  This enables powerful single sign-on scenarios where a user within a corporate network can authenticate to cloud services using the same network credentials they are used to as though they were in-house intranet applications.


Tenant Identity

This is great, but how does this get us to a multi-tenant SaaS solution?  The answer is revealed by examining the claims that come from WAAD. 

Claim Type Value
nameidentifier APdn5z19ApSKTN9xxxxHDPt_Bgc1UdY7jo0HJTC2Hxg
givenname Nicolas
surname Martin
name nmartin@broadensoftwarereach.onmicrosoft.com
tenantid cd32ef19-xxxx-yyyy-a240-d253e59a2b6d
objectidentifier 4224b237-xxxx-yyyy-b068-5e04c35d8221
identityprovider https://sts.windows.net/cd32ef19-xxxx-yyyy-a240-d253e59a2b6d/
authenticationmethod http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password
authenticationinstant 2013-09-16T01:41:14.000Z

The important claims are the name, tenanted, and identityprovider claims.  Name is the globally unique user name.  It is globally unique because it is fully-qualified with the domain name of the AD in which the user object resides.  In this case, the AD in my Azure subscription is called “broadensoftwarereach” and Microsoft was nice enough to wire up all the DNS under onmicrosoft.com for me.  In a production scenario, you can define your own domain instead of using this auto-generated one.  The tenantid claim is the unique identifier of the AD instance itself, while identityprovider is the WS-Federation issuer that created and signed the token (note the tenantid value in the URL).  These claims are what enable an application to easily be multi-tenant, because our application can handle authentication from multiple WAAD tenants and we can identify who the user represents via these claims.


Provisioning

In order to work with multiple WAAD tenants, a user in the Global Administrator role of the WAAD tenant has to give consent to the application.  There are a number of steps in getting this consent.

  1. WIF does not recognize the issuer as a known tenant and redirects the administrator to a consent page hosted by WAAD.
  2. The administrator gives consent to the application.
  3. The WAAD tenant becomes aware of the application, and the application becomes aware of the new tenant by adding it in a repository of recognized tenants.
  4. The administrator gets a redirect back into the application from WAAD.
  5. The administrator now accesses the system from a known tenant.
Figure 2: Provisioning a new tenant to the application via WAAD.

The flow in Figure 2 takes over after the flow in Figure 1, but represents what happens when an administrator authenticates to the application from an unknown WAAD tenant.  After step 5 is where you can set up any billing, resource provisioning, or any other processes that need to take place in order to effectively work with the new tenant.

Using this technology for multi-tenancy is a powerful first step in taking an application to the SaaS model.  

Share:

About The Author

Senior II Consultant, Enterprise Microsoft Solutions
Nick is a senior consultant in the Columbus office’s Enterprise Microsoft Solutions practice. His passions are learning new ways to deliver software that impresses clients using the latest technologies and Agile methodologies.