Using Azure AD Directory Extensions with Calendar Publishing

I ran through a setup three weeks ago where I used the “Directory Extensions” preview feature in Azure Active Directory to show how I could store an extra id on the user object and use this attribute in a different web app:
http://mobilitydojo.net/2014/04/08/extending-your-azure-active-directory-part-1/

Not feeling entirely done with creating samples I’ll be building another web app showing another scenario where directory extensions might be a useful approach. We’ll extract some data from Office 365 (Exchange Online more specifically), and insert into Azure AD and re-use it.

Exchange Online has this neat feature where you can publish your calendar externally so anyone can check it without being a member of your Active Directory. Actually, it’s not just Office 365 users who get this – Exchange 2013 on-prem can do so as well, but this sample will only explore the clouded version. (You can probably tweak it to work with a local Exchange Server if you like; the differences are probably fairly minor.) I’m not saying there aren’t drawbacks to using this feature, you certainly should not expose all details in your calendar to the general public, but it can be useful in a couple of scenarios and you don’t have to share all the details either.

Read more

Extending Your Azure Active Directory – Part 2

In the previous post we built a web app that would let us add a custom attribute to our Active Directory tenant in Azure AD, and manipulate the value of this attribute on a per user basis. If you haven’t read the previous article I strongly suggest going back and doing so, or this might not make much sense Smilefjes

In this part I’m going to build another app that will use the information the first app provisioned into Azure AD. The first app let me register YubiKeys, and this app will let me authenticate based on these keys. The code is fully functional without the physical keys, so you will be able to follow along even if you don’t have one in your hand.

This app could have been implemented as a Windows Phone app, an Android app, or what have you really, but to make it available for all scenarios without too much fuss I’m building it as a web app. (Which is an entirely plausible use case by it’s own merits.)

Read more

Extending Your Azure Active Directory – Part 1

I don’t know about you guys, but I use Microsoft Azure all the time (it’s not Windows Azure any longer). Not for everything I do, I still have servers at home and at work, but if I need to deploy something to "the cloud" that cloud is often Azure. One of the features in Azure I’ve taken a liking to recently is Azure Active Directory, which lets you either extend your current on-premise AD or setup a cloud-only AD. Since this AD provides APIs as well as the UI management tools you would expect by default this gives you the benefit of not having to implement a separate identity system for stuff that you create, and users can reuse the credentials they already have instead of having to remember multiple logins.

The general workings of Azure AD works may be familiar to you already, so I’m not going to do an introduction on how to get started with Azure AD. If however it doesn’t ring a bell you may check out MSFT’s site:
http://azure.microsoft.com/en-us/services/active-directory/

To follow along with this article you will need access to an Azure AD tenant. It doesn’t matter if it’s cloud only or the full DirSync experience. The code stays the same.

When you break it down to the basics you could say that Active Directory is just a database. For a long time it’s been possible to use AD as a database by "extending the schema", but if you’ve ever tried to convince a sysadmin that "hey, my app wants to put extra stuff into your directory" you will know that’s a pretty tough sell. (I am equally hard to convince if an app I didn’t create wants to insert config data into my AD, so I don’t blame the admins.)

Microsoft recently introduced a new feature called "Directory Extensions" to Azure Active Directory. Still only in preview, but that’s not a problem as far as introducing it to the lab 🙂 These extensions live exclusively in the cloud, (if this will change later on I do not know), so they do not get synced back to your on-prem AD.

A blog post from the AAD Graph Team should give you an idea:
http://blogs.msdn.com/b/aadgraphteam/archive/2014/03/06/extend-azure-active-directory-schema-using-graph-api-preview.aspx

Graph API is the term for the RESTful interface that developers use to access the Azure Active Directory tenants; you don’t get to talk directly to the underlying files that make up the directory 🙂

The idea is that your app might be in the possession of data that it would make sense to attach directly to the user object in the identity directory, and/or data that might be of interest to other apps. This data should be inserted in, and extracted from, Active Directory in a manner that doesn’t interfere with the internals or break something.

It’s not necessarily easy at first glance to understand what this feature could be used for, or how it works, so I thought I’d try to create a walkthrough where I implement a simple scenario to illustrate what you can leverage these extensions for.

Read more