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

Microsoft provides a RESTful API for Exchange – Part 2

The boilerplate code we compiled in the first part of this walkthrough is clean and simple, but it’s only the basic stuff you need to get started, so we’ll be making some changes to this code to turn it into something to build upon. (The common Office 365 authentication bits don’t need changing, I’m thinking of the Exchange specific parts.)

First you can remove the stuff we don’t need, (it doesn’t break anything if you leave it there, so if you prefer to have the templated code there while we work that’s ok).
Delete the following files:
ExchangeSampleController.cs
Views/ExchangeSample (folder)
Project_Readme.html

Create a new class in the Models folder.
CustomOffice365OWA_09

Type in or copy/paste the following code:

This should be the attributes we can expect for an email message. You’ll also notice I’ve tagged some of the properties with [ScaffoldColumn(false)] to avoid having them clutter up the view.

Read more