Bring Your Active Directory in Your Pockets with ACS, OAuth 2.0 and the New Windows Azure Toolkit for Windows Phone 7

As promised last week, today Wade released the 1.2 version of the Windows Azure Toolkit for Windows Phone 7. And again as promised, this version has full support for ACS!

Using the new feature is super straightforward: you can see that by yourself in the quickstart video in which I walk through the simplest ACS configuration.

As mentioned in the teaser post last week, we purposefully kept the VS template very simple. As a result, the initial setup ends up with one application which supports Windows Live ID, Yahoo! and Google, the identity providers which are pre-configured within ACS.

However, once the project has been created nothing prevents you from working directly on you ACS namespace for adding new identity providers, such as Facebook or even your own Active Directory; those identity providers will automagically show up in the list of IPs in the login screen without he need of changing a single line of code. Want proof? Read on!

Adding a New WS-Federation Provider (like ADFS2)

Here I’ll assume that you went through the steps I show in the quickstart video and you ended up with the basic ACS application as created by the toolkit.

If you want to enable your users to sign in the application using their Active Directory accounts, you can go directly to the ACS namespace you are using and add you AD (assuming you have ADFS2 deployed) as an identity provider.

Note: Right now the toolkit bits are still handling access at the account level, which means that your users will need to go through the same sign-up step you have for users coming from social providers; however this does not subtract anything to the joy of being able to reuse your domain credentials on a device, instead of having to memorize yet another password. In the future the integration will be even more seamless: think claim mapping rules, along the lines of what we’ve done for integrating ADFS2 with Umbraco.

Well, let’s do it then: it will only take a minute!

As usual I don’t have an ADFS2 instance on my laptop, hence I’ll simulate it using SelfSTS. This time I picked the  SelfSTS1 folder from the assets of the ACS and Federation lab, copied it under c:temp and modified it a bit to emit a different set of claims:

I also changed its port from the config, generated a new certificate, hit Start and refreshed the federationmatadata.xml file (hint: use the URL from the metadata field to open the file in Notepad, then save it over the old metadata file). Those may not be strictly necessary, but I always do that for avoiding collisions.

Now that you have your ADFS2 simulation up & running, go to your namespace in the ACS portal at https://YOURNAMESPACE.accesscontrol.windows.net/v2/mgmt/web. From there go to Identity providers, hit Add, keep the default ws-federation and hit Next.

From here you can add your SelfSTS instance. Remember, it simulates your AD! If you have an ADFS2 instance, use that instead. Enter whatever name you want in the display name and login text link fields, upload the metadata file from your SelfSTS, scroll to the bottom of the page and hit Save.

Now click Rule groups form the left-hand menu, click on Default Rule Group for WazMobileToolkit, hit the Generate link, accept the defaults and click the Generate button. You can also hit Save for good measure, if you are superstitious .

And you’re done! Go back to Visual Studio and start the portal/service and the phone client as shown in the quickstart. Here there’s what you’ll see on the phone app:

That’s right! Just like that, now your AD appears as one of the options. Neat. If you pick that option, ACS will contact SelfSTS for authenticating you. If you would be using a real ADFS2 instance at this point you would be prompted for your credentials: but SelfSTS is a test utility which automatically authenticates you, hence you’ll go straight to the next screen:

…and from now on everything is exactly as for the social providers: the user gets an entry in the system, which will be used for handling authorization. You can see it in the Users table in the management portal.

Let me reiterate: in addition to being able to use credentials from Windows Live ID, Yahoo and Google, the user can now reuse his domain credentials to sign in from one Windows Phone client to one application whose backend is in the cloud (Windows Azure). And enabling all that took just few clicks on the ACS management portal, no code changes required.

Now, do you want to hear a funny story? We did not plan for this. I am not kidding. I am not saying that we are surprised, I totally expected this, what I mean is that this scenario didn’t take any specific effort to implement, it came out “for free” while implementing support for ACS and social providers. 
When you admit users from social providers in your application, you don’t receive very detailed (or verifiable, excluding email) information about the users; hence the usual practice is to create an account for the user and mainly outsource credential management to the external identity providers.
In the walkthrough above I treated my simulated ADFS2 exactly in the same way, and everything worked thanks to the fact that we are relying on standards and ACS isolates the phone application and the backend from the differences between identity providers.  It’s the usual federation provider pattern, with the twist demonstrated in the ACS + WP7 lab; in a future blog post I’ll go a bit deeper in the architecture of this specific solution.

What could we accomplish if we’d explicitly plan for an identity provider like ADFS2? Well, for one: provision-less access, one of the holy grails of identity and access control
ADFS2 sources data from AD, hence can provide valuable information about its users (roles, job functions, spending limits, etc) which carries the reputation of the business running that AD instance. This means that we could greatly simplify the authorization flow, skipping the user registration step and authorizing directly according to the attributes in input. As mentioned above, we already have a good example of that in the ACS Extensions for Umbraco; that’s a feature that is very likely to make its way in the toolkit, too

There you have it. The bits are in your hands now, and we can’t wait to find out what you’ll accomplish with them! If you have feedback, please do not hesitate to visit the discussion section in http://watoolkitwp7.codeplex.com/. Happy coding!