Welcome to part three of a blog series based on my latest PluralSight course: Applied Windows Azure. Previously, we’ve discussed Azure Web Sites and Azure Worker Roles.

Motivation

Windows Azure Active Directory (WAAD) is another important building block offered as part of the Windows Azure platform. You can think of WAAD as a repository for your organization’s directory data in the cloud. Directory objects include users and groups along with their identity and access information.

By externalizing the directory data into a common location (WAAD), it is possible to provide a single sign-on and sign-out experience for enterprise applications, as well as SaaS offerings.

While WAAD is a cloud-based service, you can use it for on-premises in addition to cloud-based applications.

You can also synchronize your on-premises AD with WAAD. This option is becoming quite popular among customers who have mainly relied on federation as a way to project their on-premises organizational structure to services such as Office 365. Observant readers likely surmised an important detail from the previous statement – WAAD is providing core identity and directory services to Office 365.

Finally, WAAD also offers the ability to integrate with third-party SaaS providers such as Box and SalesForce. This means that users can log on to these SaaS services using their WAAD credentials.

Scenarios

Based on the above description, it’s not hard to come up with scenarios where you can use WAAD. Perhaps you are building an on-premises web application and don’t have access to a local AD, or don’t want to maintain your custom identity store. In such scenarios, WAAD serves as the identity store.

Another scenario where WAAD is becoming important is a multi-tenant app. Imagine you are an ISV building a web app that you want to sell to a customer who is already an Office 365 subscriber — and consequently, has a WAAD tenancy setup. In such a scenario it makes sense for your app to obtain permission to access that customer’s existing WAAD tenancy (rather than setting up a new WAAD tenant). Turns out that WAAD facilitates such “permission request and approval workflow” use, so an app developer can explicitly request access from the administrator of WAAD tenant. This ability to work with one or more instances of WAAD is what I referred to as the multi-tenant app earlier.

Core Concept

The following diagram depicts the core WAAD concept. At the center of the diagram is the repository for any data (users, groups) that you want to store in WAAD. You can  get this data into WAAD via the Graph API or by synchronizing the contents of an on-premises AD instance (using an aptly named tool ‘dirsync’).

Once you have populated your WAAD instance, you can connect to it using well-known authentication and authorization protocols such as WS-Federation, SAML-P and OAuth 2.0. and claims such as SAML and JWT. Our industry has propensity to invent new security protocols all the time. Fortunately it is the WAAD team’s responsibility to add support for new protocols, thus allowing you to focus on your core business functionality.

We briefly touched upon the Graph API earlier. It is the REST-based API that makes it easy query and manage directory objects such as users and groups. You are probably wondering why we need the Graph API and why the on-premises ways of accessing data stored in AD (ADO.NET or ADSI) aren’t enough. Turns out that directory data stored in WAAD can be far more malleable and unstructured. In addition, you want to able to query for this information internet friendly protocols. This is why having a REST-based interface designed around a graph offers a more flexible approach for querying data. In addition to the REST endpoint, you can allow query data over OData v3.

Design Considerations

Here are some design considerations as you look into using WAAD:

  • WAAD is not AD in the cloud; you don’t “domain join” cloud-based machines to it. The kinds of directory data you store and how you access them needs to be carefully considered.
  • Determine which authentication protocols and claim types (amongst the ones supported by WAAD) will be required. Determine how you will work with the metadata documents that WAAD will generate based on the authentication protocols you choose.
  • Determine how will populate and manage the directory objects in WAAD.
  • Do you need verification methods in addition to username and password? If yes, consider Windows Azure Multi-factor authentication that supports additional verification methods, such as phone or text messages.
  • When setting up access to third-party applications using WAAD, determine if the single sign-on will be based on password caching or federation.

Summary  

Windows Azure Active Directory (WAAD) offers a convenient way to externalize the identity and authentications requirements of your on-premises and cloud based applications. It supports an ever-growing list of authentication protocols and claim types. Being a cloud service, it brings with it high availability and scalability. Directory data stored in WAAD can be accessed using a REST-based Graph API.  WAAD can also be used to provide enable single sign-on with third-party services such as Box and SalesForce.