Windows Azure Active Directory: Microsoft’s stab at cloud identity

Cloud-driven identity is the evolutionary next step from the dichotomy of traditional enterprise directories and application-level user information stores. But as such, it is also a very elusive concept. In this article, I try to define cloud identity in a practical, useful manner and look at the problems Windows Azure AD (“WAAD”) attempts to solve.

This article is intended to be useful for IT professionals and developers who may only have a superficial understanding of identity management and related issues. If you already understand AD and enterprise IDM, feel free to skip ahead to my actual treatise on WAAD.

 

The drivers for cloud identity

These three people sum up the key problems we have now.

It’s not like there hadn’t been attempts to fix this. Consumer single sign-on is currently mostly powered by a few big identity providers – namely Facebook, Google and Microsoft Accounts (formerly known as Live ID). Fair enough, but this does little for the distributed enterprise.

IT admins’ headaches are often medicated by identity management systems – software that is geared towards synchronizing disparate notions of user across systems. These systems are a quagmire themselves, and a source of meta-headaches. They also often involve their own authorization and SSO systems, further adding to the complexity of identity management. One more problem is the management of extranet accounts – not only are the poor IT admins in trouble within their own organization, but they are often also required to react to personnel changes within their partner companies.

Developers can benefit from various SSO solutions (OpenID/OAuth in the web for consumers, Kerberos and friends in the enterprise), but they rarely offer a unified view of the identity. Devs will always have their User tables for storing information specific to that application, but couldn’t they have an easy way of getting the basic user information for each new application?

The promise of IDMaaS

Put all that together, and you have a case for IDMaaS – Identity Management as a Service. Ideally, a cloud-based information store could contain key facts on your identity and pass it on to parties you define trusted. They could then augment this information by their own knowledge of you.

To illustrate the issues further, I’ll borrow a couple of slides from Microsoft, laid out in a fairly enterprisey context. Let’s first start with the current situation:

And then the optimistic view of the future:

 

In the cloud identity vision, a single repository of user identities could serve all the applications and resources listed on the right side of the chart. But also, it could integrate with various other parties: the items on the left side of the chart are actually other providers of identities. This provides a slew of interesting federation scenarios. For example, given administrative consent, you might be able to configure your digital passport (granted by the government) to provide access to your corporate mail server. You would still be identified as your corporate self, but you could log in with your official digital identity.

Of course, even the diagrams above are simplified, and they also slightly misrepresent Microsoft’s intent: They are not trying to position WAAD as the single identity nexus of the universe, but rather as one hub. There could be several of these hubs – for example, one per company – which could possibly have federation set up between them. See this blog post for Microsoft’s views regarding distributed authentication systems and this particular question.

User data store meets a directory

There is one more piece to be laid out here. For the discussion above, I have avoided the use of the word “directory”. This is because most applications really have user data stores, not directories. Still, Windows Azure Active Directory, as will be discussed below, is aiming to eventually be a directory in the full sense of the word. So, let’s define some terms first.

A user data store is a “user table”, a list of users and their attributes. A directory service, as the term is typically used in IT, is an information store that contains not only users and their various groupings, but also information on an organization’s topology (physical sites, logical organization) and resources (computers, printers etc.). This feature makes sense particularly in an enterprise context, where an application might benefit from enumerations such as “all printers in the same physical location as the user”.

A key component of a directory is also its awareness of hierarchies. Typical directories have at least container hierarchies. The most common node of a container hierarchy is the “organizational unit” (OU), which could represent a division, team, factory or whatever is appropriate. Users and their computers would then be organized under their OUs. In addition, objects may themselves have OU-crosscutting hierarchical relations such as manager/report.

A typical full-fledged enterprise directory reaches further than one might image from the discussion above. Perhaps the most common of them, Microsoft’s Active Directory, enables administrators to alter the directory schema to include almost any kind of resources, thus turning it into a general purpose repository of information. Such extension fits the scheme of abstract resources quite nicely, and greatly enhances the functional range and importance of a typical directory installation.

For example, one of the most common Windows Active Directory resource types is the Group Policy Object (GPO), which is a set of instructions for computers. A GPO might configure a local security policy or set up a connection to a local resource. A GPO added to an OU would have its rules applied to all computers under that unit, enabling IT administrators to issue administrative directives such as “install this new printer on all Boston marketing laptops during the next user login”.

As a testament to the open nature of a directory, this policy system isn’t logically a service provided by the directory itself. Rather, it is a feature of the operating system that just uses the Active Directory as a data source and control channel.

Understanding Windows Azure Active Directory

Windows Azure Active Directory, or colloquially just WAAD, is Microsoft’s attempt at bringing the ubiquitous Active Directory to the cloud. WAAD is tough to grasp, and Microsoft doesn’t seem to be laboring to make the concepts clear. It is currently in a state of preview, and far from completion in terms of features.

First and foremost, WAAD is nowhere near an Active Directory ported to the cloud. It will one day be, but at this point, WAAD is more like a user data store than a real directory.

As this screenshot from the administrative portal shows, the available features revolve around users and groups. One other thing that immediately pops up is the reference to Office 365. How does this work?

In fact, WAAD is not a new technology. Since its inception, Office 365 has always created a WAAD installation (a “WAAD tenant”) for each Office 365 subscription, and the same goes for Windows Intune. The new thing: You can now also create WAAD tenants without subscribing to those services.

There are four approaches to administering WAAD. If you’re an Office 365 subscriber, you can use the classic Office 365 portal to manage the information. Similarly for Windows Intune. But for both standalone tenants and O365/Intune-linked directories, you can use either the Azure AD Portal (see the screenshot above) or a set of PowerShell commandlets (which are really branded as Microsoft Online Services cmdlets, but work for standalone WAAD tenants as well).

Again borrowing a slide from Technet:

The WAAD admin portal is fairly simple. It enables you to create users and groups in domains, which you can have several in a single tenant. You cannot create an OU hierarchy for users, and there is no concept of a resource.

But all that is likely to change at some point: There is all the reason to believe that WAAD will evolve to become more and more full-featured. Windows Intune is already showing the way by enabling various groupings and adding devices; how much of this data is actually stored inside the WAAD is not known, but the direction of the platform is clear.

Federation with on-premises AD

Most organizations currently have their own directories, and they are powered by on-premises Active Directory installations. Office 365 has long supported federation with local AD installations, and thus WAAD does the same.

Federation is best viewed as a process of projecting your on-premises directory onto the cloud. Although Microsoft calls it directory synchronization, only a very narrow slice of information actually gets replicated.

There is one more important thing to note. In the normal federated configuration, the authentication credentials are stored in the on-premises directory. All authentication happens against the on-premises Active Directory, but the authentication tokens are accessed through the cloud AD. This enables single sign-on scenarios even for applications running in the cloud. Doing this requires quite a bit of ADFS magic that is beyond the scope of this article.

Without federation, the credentials are stored in WAAD, and the domain is thus completely hosted in the cloud.

Also, federation is by no means bound to the use of Office 365 (or Windows Intune): You can have an Office 365 installation with the whole directory hosted in the cloud, and you can have just a raw WAAD tenant with cross-premises federation enabled.

The development story

There are two major scenarios for WAAD-based application development. The first one is about building an app for a single organization, while the second one provides support for applications that are sold for several customers. We’ll cover the first scenario here, and the second one in the next chapter.

If you’re developing a business application for a single company (you or your client), you can use WAAD to handle the authentication. If the client organization has WAAD with federation (sync to on-premises), great – they can access your app with their own domain credentials and get single sign-on as an added bonus. Even if they don’t federate, you may want to use WAAD as the authentication backend for your application, just replacing your app-local user data store. In this case, you would create your own WAAD tenant to serve as the authentication backend.

You can use WAAD authentication regardless of whether your app runs on Azure, a 3rd party hosting provider or even on-premises. Also, WAAD supports a bunch of open protocols, making it available regardless of your programming platform.

Before you start, in order for the application to have access to the WAAD tenant, the application must register to use the tenant directory. This registration is called a Service Principal, and it is stored in the directory. Unfortunately there is no UI in the WAAD admin portal for managing service principals, but you can use PowerShell for that. A Visual Studio extension also helps you set up the authentication, adding the service principal in the process. Once SP setup is done, everything else is platform-agnostic and based on standard protocols.

The picture below illustrates a possible setup for your application.

For most apps, authentication is typically done using WS-Federation or OAuth – standard protocols, but different from how you’d traditionally integrate with a directory. It is all Claims-based, which is a complicated concept in itself, but .NET developers are happy to have .NET Framework and Windows Identity Foundation (WIF) hide much of the detail. Other platforms have similar libraries available.

One particular quirk is that the normal claims authentication channel doesn’t provide you with much information except the user ID. In order to browse the directory for information such user’s as group membership, you need to access the WAAD Graph API, which is based on OData (again, a relatively complicated stack made easier by the abundance of tools for various platforms). If you’re interested, you can take a walk around the Graph API’s data model using the Graph Explorer tool with an openly available demo company provided by Microsoft.

Long-time directory developers may notice that LDAP and Kerberos are gone. For now, that’s the truth, although there are small hints of LDAP’s possible re-emergence. At any rate, the WAAD Graph API serves much of the same purpose.

After I had already written much of this article, Microsoft announced on 2012-11-28 that the Windows Azure management portal now supports WAAD-based authentication. That story is really nothing new from the WAAD perspective, but it is a practical example of what you can achieve with WAAD and the development tooling described above – and of course, a good improvement for Azure in general!

Developing in a more SaaSy manner

The previous development scenario discussed something where WAAD just simplified something that was already doable. What makes cloud directories really interesting is the possibility of building an application with multiple authentication tenants.

In this scenario, your application forms a relation with the Windows Azure Active Directory by registering itself in a portal called Seller dashboard. After this, your application can provide a simple web link to a page where a tenant administrator can log in and grant the application limited access to his organization’s directory. Once done, any credentials in the organization’s directory are also valid for logging into your application.

The above scenario is, again, agnostic of possible federation arrangements. Some of the associated tenants may be federated from on-premises Active Directories while some may reside completely in the cloud. To you as a software developer, all that matters is that you redirect the unauthenticated user to the Windows Azure AD login service, which will upon a successful login return the user to your site, with appropriate claims attached in the request.

It’s still in the works

What I have described above is reality: it is openly available right now, and you can test it. But it is in preview, and this leaves a few things in the dark. First of all, there is no information on where Microsoft will take WAAD next, and how soon. Although it’s most likely safe to invest on the platform as it stands, it is still a preview.

One important thing is that WAAD is free, a significant difference from (almost) any other Microsoft cloud service. This makes business sense, too: Getting organizations to trust Microsoft as their cloud identity provider helps enormously in bolstering Windows Azure as a platform of choice for many applications.

But being in preview also means that there are unpolished corners. If you (as a normal user) have several WAAD logins in different tenants you may end up with strange errors trying to log out from them in order to change your identity. The developer experience is nice until you stray from the beaten path, at which point you suddenly have to understand all sorts of system underpinnings to recover.

Even with all these issues, WAAD is promising and certainly shows a way ahead. The coming months will quite likely reveal some of Microsoft’s planned next stages in the WAAD vision – and hopefully, bring it to the general availability stage.

 

P.S. If you go down the implementation route with your own application, I suggest you check out my colleague Lauri’s series of blog posts on the practical issues related to WAAD authentication.

Tags: claims-based identity, security, Windows Azure Active Directory