Provisioning a Windows Azure Active Directory Tenant as an Identity Provider in an ACS Namespace–Now Point & Click!

About one year ago I wrote a post about how to provision a Windows Azure AD tenant as an identity provider in an ACS namespace.

Lots of things changed in a year! Since then, we spoke more at length about the relationship between AAD and ACS. If you didn’t read that post, please make a quick jaunt there as it’s super important you internalize its message before reading what I’ll write here. Done? excellent!

In the past year Windows Azure AD made giant steps in term of usability and features set, and hit general availability. That means that many of the artisanal steps I described in the old walkthrough are no longer necessary today. In fact, you can do everything I’ve described there just by filling forms in the Windows Azure portal!

The idea behind the scenario remains the same. You have a web application which trusts an ACS namespace. You want one or more Ad tenants to be available among the identity providers in that namespace. Hence what you need to do is

• Provision in the AAD tenant the ACS namespace in form of a web app (so that it can be a recipient of tokens issued by AAD)
• Provision in the ACS namespace the STS associated to the AAD tenant

The rest is usual ACS: create RPs, add rules, the usual drill (which can be automated by the Identity and Access tool in VS2012. No equivalent capability in VS2013 exists, see the note at the beginning of the post).

Too abstract? Let’s turn this into instructions.

Provision in the AAD tenant the ACS namespace in form of a web app

Here I’ll assume you already have a Windows Azure subscription, an ACS namespace and a Windows Azure AD tenant. Let’s say that your namespace is https://justforyoumaarten.accesscontrol.windows.net.

Navigate to https://manage.windowsazure.com/, sign in, head to the AD tab, click on your directory, click on the applications header, and hit the “ADD” button on the bottom center area of the command bar.

Leave the default (web application), assign a name you’ll remember and move to the next screen.

Here, paste the namespace in both fields. Why? Simple. The URL is where the token will be redirected upon successful auth, and you want that to be the ACS namespace. The URI is the audience for which the token will be scoped to, and any value OTHER than the entityID of the ACS namespace (as you find it in the ACS metadata docs) would be interpreted by ACS as a replayed token from some MITM. Sounds like Klingon? Don’t worry! That’s a level of detail you don’t need to deal with, as long as you follow the above instructions exactly.

Move to the next screen.

ACS will make no attempts to call the Graph, hence you can leave the default (SSO) and finalize.

Congratulations! Now your AD tenant knows about your ACS namespace and can issue tokens for it!

Provision in the ACS namespace the STS associated to the AAD tenant

Time to do the same in the opposite direction. Before you leave the app list, there’s a last thing we need to do here: click on the “view endpoints” command on the bottom of the bar.

When you do so, the portal will display the collection of endpoints that you need to know if you want to interact with your AAD tenant at the protocol level:

You’ll want to put in the clipboard the fed metadata document, as it will be what we will use for introducing our AAD tenant to the ACS namespace.

Click the big back arrow on the top left corner of the screen, which will bring you back to the top level active directory screen. This time, click on the header access control namespaces.

Here you’ll find your namespace. Select it, then click on the “manage” button in the bottom command bar. That will lead you to the ACS portal for managing the namespace.

Head to the Identity providers section. Once here, select WS-Federation identity provider and click next:

Choose anything you want as display name and login link text. Paste the address of the AAD tenant’s federation metadata in the URL text field of the metadata section.

aand you’re done! Hit Save.

App work

All the service side work for enabling the scenario is done. All that’s left is the work you’d need to do for every RP app you want to create in the ACS namespace. For that, the instructions are pretty much the same as in the old post: use the identity and access tool for VS2012, and that will take care of creating the RP entry, create the associated rules, configure your app to outsource web sign on to ACS, and so on. I won’t repeat the step by step instructions here, but to show my good faith I’ll throw in a couple of screenshots to demonstrate that it works on my machine®

Here there’s the tool, hooked up to the ACS NS:

Here there’s the familiar HRD page:

Pick AAD and…

…you get in with your organizational account.

Neat, if I may say so myself!

Wrap

I’ve been wanting to write this post for a while, but of course I never found the time… then, about 30 mins ago somebody on a mail thread asked if there was a point & click solution for this scenario. I sat down, went through the motions while occasionally snapping screenshots and writing my rambling instructions… I was prepared to go to sleep much later, and instead here there’s the finished post already! I love how Windows Azure AD matured as a technology in such a short time