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”.image

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.

OUTree 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

imageMost 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.

image 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

Confusing product naming

The exact meaning of “Windows Azure Active Directory” is a bit muddled. Microsoft seems to be using WAAD as a term that contains all of the identity effort inside Microsoft’s Cloud services – including older, generally available Windows Azure Access Control Service, which is not a directory (but can be used together with one).

When this article mentions WAAD, it means just the directory part, the one we’re describing here. When Microsoft talks about WAAD (such as claiming “Facebook integration”, they’re really saying that ACS has Facebook support – “WAAD the Directory” doesn’t, at least so far. Eventually these two will probably merge enough to make the difference irrelevant, but until that, be careful.

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.

Jouni works as a consultant focusing on Microsoft technologies and technology strategy issues. Prior to this, he has an extensive background in development, IT administration and business management. He's been doing this for a living since 1995.

21 Responses to “Windows Azure Active Directory: Microsoft’s stab at cloud identity”

  1. Jouni Heikniemi

    Dec 03. 2012

    … and I would be remiss if I didn’t extend special thanks to Mika Seitsonen and my Offbeat colleagues for proofreading and commenting this article. It wouldn’t be this comprehensive without your efforts.


    Jul 19. 2015

    Quality articles or reviews is the important to be a focus
    for the visitors to visit the site, that’s what this web page is providing.

  3. また、あなたのフィードを取っています。どこの誰が書いているような完全な方法で情報のようなものを得ることができますか?私は、着信週プレゼンテーションを持っている、と私はそのような情報に目を光らせています。ファンタスティックな情報を
    水着 レディース 新作【フレアTOPビキニ 2点セット】レディース/レディス/Ladies/女性/女性用/【10,800円~送料無料】【内祝い_お返し_結婚祝い_お誕生日_出産祝い】:レディース通販のソラーラ

  4. かなり 優秀良い…この記事はほとんど値しない何も …ハハハ単なる冗談:S …素敵なライトアップを:Pの
    【楽天市場】★20時~4H限定P10倍★【送料無料】 畳ベッド セミダブルベッド 日本製 たたみ付 手すり付 畳ベット たたみベッド 大川家具 宮付き 棚付 シングルベット 和 モダン 介護ベッド ベッド ベット:頑張る家具屋 【タンスのゲン】

  5. アイブ氏が言うようになった、単独でのレイアウトは、私は再びこのウェブサイトに戻ってきました。しかし、今アイブはyouveは言うようになったかを確認すること、アイブ氏は、世界とそれを共有するようになりました!

  6. 見るアーケードセルゲーム無料のモバイルゲームの有名なceolebritiesについての私のページをチェック!投稿の乾杯。私の神を
    完売目前★【メール便送料無料】【襟デザインボーダーTシャツ(t557)】tシャツ レディース 半袖 ボーダー Tシャツ 半袖 レディースカットソー 半袖  reca レカ※セール品の為、返品交換不可です※:reca (レカ)

  7. 私は純粋にあなたのインターネットのウェブを楽しみます正しいは|の最高の|}ウェブページでは、ネジ止めされている – それは不思議です。 おそらく可能性私はあなたのスクリーンショットを郵送しますか? ;仕事とにかく、あなたのを続けます私は本当にあなたを読んで感謝しています。 追加 しかしにこのに関する事追加 ブログ
    ベジタブルソープ 野菜の雫 カボチャ アボカド トマト 野菜石鹸 ソープ 石けん 美肌 弾力肌 保湿肌 うるおい【内祝い_お返し_結婚祝い_お誕生日_出産祝い】【父の日_お中元_ギフト】【結婚式_引き出物_香典返し】:レディース通販のソラーラ

  8. *あら! 信じられない ライトアップ男。ウルRSSで 私は私がよ経験していただきありがとうございます。それに加入することがなぜできないのか分かりません。 ジレンマ 取得同一のRSS誰がありますか?親切に回答を知っている人。 Thnkx
    ★【デビフ】【dbf】おすわりくん スティックタイプ?ビーフ 40g[LP]【TC】【RCP】【e-netpet】【0530pe_fl】:犬とEnjoy!ドッグパーク

  9. あなたは どのようなプラットフォームやテーマがありますか? 場所を正確に私はそれらを購入することができますか? X
    ★廃番 ユニチャーム デオサンド トイレに流せるタイプ 8L【D】[EC]【RCP】【hl150515】:Pet館~ペット館~

  10. スポットを開始することができます|このライトアップの仕事関数を、I 実際にこの顕著信じるインターネットサイト要求かなり もっと考察。数多く| 素晴らしい読むために多くの情報。 本当に いいポストおやおや
    ※欠品※カリフォルニアナチュラル グレインフリー(穀物不使用) チキン 1kg[AA]【D】【RCP】:犬とEnjoy!ドッグパーク

  11. ありがとう別のニュース記事をありがとうございました。イムは、本当に興奮し、私はブログのように多くは、誤解を招く情報を持って読んでいアイブので、この記事を見つけることができました。

  12. おかげで、youreの多くを公開しようとしていることを教えてください。私は(イムはちょうど自分自身追いつい)あなたはしばらくの間、追加のウェブログを書かれてhaventは気づきます。あなたのブログを逃したになるためにはあまりにも重要です。ホードは、このウェブログが消え見るために恥だろう、このテーマについて、これらの知識を言ってあまりを取得しました。インターネットは、人があなたを必要としています!そのようなあなたはここで言及した1など

  13. のためにもう一度戻ってきます。どこにあなたのブログの記事のための情報を見つけましたか?公報では、多分ぼろや用語集、またはのみランダムにWeb上の?返信してください:)。

  14. のおかげで、私は年齢のために、このテーマについての詳細は求めているとあなたは、アイブ氏はこれまでに発見されたベストです。

  15. ウェブ ウェブサイト、同様にI 思う属性|感触} とスタイルを保持している素晴らしい {特徴|機能|機能と考えています。

  16. これは本当にあるに| 対象トピック 優れた非常に良い良い | について話が話します。時々私はReditにこのようなものをFAV。このライトアップ きれいその群集とし、おそらく文句を言わ行います。私はになるだろう 特定しかし何か他のものを提出します。

  17. ファンタスティックは我慢しました!これは、この問題についてのうち発見人々の数を支援する可能性があります。あなたはこれらと一緒にビデオクリップを組み込む必要がありますか?それは間違いなく出て支援することができます。あなたの目的は、その場で、あなたのためでした。私が最も可能性の高い私の仲間にすべてを説明する必要はありません。私は単にここにそれらを指示することができます。とにかく、私の言語で、このようにたくさんの良い供給ができなくなります。うわー

  18. ねえ!マン..美しい.. ワンダフル ..私はよブックマークあなたのインターネットサイトとは、フィードalso’I’mを取る嬉しく明らかに数多くの有益な詳細ここで提出内側​​正しい、我々はこれまで開発されますしたい持っている必要があります はるかこの点での戦略、教えてくれてありがとう。 。 。 。 。 。

  19. ! I 単に用に巨大な親指を与えたい優秀データあなたは可能性持っている権利を適切ここで、この上ポスト。私はそう来るということだもう一度ウェブログにするためはるかすぐ。

  20. ゴマ待つことはできません。それは、このインターネットサイトに出くわすために私にいくつかの時間がかかったが、それは時間の価値がありました。私はこの記事がビンビンはなく、1位に葬られた気づきました。このサイトでは、第一級のもののトンを持っており、そのような検索に埋設されるように値しません。ちなみにイムは私のお気に入りにこのサイトを保存するつもり。私はアウトバックステーキハウスで今日これについて同僚とおしゃべりした

  21. 。私はあなたのポストに入れて、あなたの品質を愛します。これに類似して前方に移動してください。

Leave a Reply