Using the Windows Azure Access Control Service in iOS Applications

Nossir, there is nothing wrong with my blog the screenshot above is indeed taken from a Mac desktop, and the one you see on the center is actually an instance of the iPhone emulator. What you should notice, however, is the list of Identity Providers it shows, so strangely similar to what we have shown on Windows Phone 7 and ACS… but I better start from the beginning.

A couple of months ago the Windows Azure Platform Evangelism team, in which I worked until recently, released a toolkit for taking advantage of the Windows Azure platform services from Windows Phone 7 applications. The toolkit featured various integration points with ACS, as explained at length here.
At about the same time, the team (and Wade specifically) released a version of the same toolkit tailored to iOS developers. That first iOS version integrated with the core Windows Azure services, but didn’t take advantage of ACS.
Well, today we are releasing a new version of the Windows Azure toolkit for iOS featuring ACS integration!

Dear iOS friends landing on this blog for the first time: of course I understand you many not be familiar with the Windows Azure Control Service. You can get a quick introduction here, however for the purpose of providing context for this post let me just say the following: ACS is a fully cloud-hosted service which helps you to add to your application sign-in capabilities from many user sources such as Windows Live ID, Facebook, Google, Yahoo, arbitrary OpenID providers, local Active Directory instances, and many more. Best of all, it allows you to do so without having to learn each and every API or SDK; the integration code is the same for everybody, and extremely straightforward. All communications are done via open protocols, hence you can easily take advantage of the service from any platform, as this very post demonstrates. Try it!

I am no longer on the Evangelism team, but the ACS work for this deliverable largely took place while I was still on it: recording the screencast and writing this blog post provides nice closure. Thanks to Wade for having patiently prepped & provided a Mac already perfectly configured for the recording! Also, for driving the entire project, IMO one of the coolest things we’ve done with ACS so far.

And now, for something completely different:

The Release

As usual, you’ll find everything in DPE’s GitHub repository: https://github.com/microsoft-dpe
There will be four main entries you’ll want to pay attention to:

• watoolkitios-lib

  This is a library of Objective-C snippets which can help you to perform a number of common tasks when using WIndows Azure. For the specific ACS case, you’ll find code for listing identity providers, acquire and handle tokens, invoke the ACS management APIs, and so on.

• watoolkitios-doc

  As expected, some documentation

• watoolkitios-samples

  A sample application which demonstrates how to put the various snippets together

• cloudreadypackages

  Those are a set of ready-to-go packages that can be directly uploaded and launched in Windows Azure, without requiring you to have access to Visual Studio or the Windows Azure SDK: all you need is to deploy them via the portal (which works on Mac, too). The packages can be used as test backend for your iOS applications.
  The packages take advantage of the technique described here to allow changes in the config settings even after deploy time. Which is a great segue for…

• The ACS config tool for IOs

  In the Windows Azure Toolkit for Windows Phone 7 we included some Visual Studio templates which contain all the necessary logic for wiring up a phone application to ACS and configure ACS to issue tokens for that app. In iOS/xCode there’s no direct equivalent of those templates, but we still wanted to shield the developer from many of the low level details of using Windows Azure. To that end, we created a tool which can automatically configure the application, ACS and Windows Azure.

Using the ACS Configuration Tool for iOS in the Toolkit

If you want to see the tool in action, check out the webcast; here I will give you few glimpses, just to whet your appetite.

This is a classic wizard, and it opens with a classic welcome page. We don’t like surprises, hence we announce what the tool is going to do let’s click next.

The first screen gathers info about the Windows Azure storage account you want to use; nothing to do with ACS yet. Next.

The next screen gathers the certificate used for doing SSL with the cloud package. Again, no ACS yet. Next.

Ahh, NOW we are talking business. Just like in the toolkit for Windows Phone 7 we offered the possibility of using the membership provider or ACS, here we do the same: depending on which option you pick, the way in which the user will be prompted for credentials and how calls will be secured will differ accordingly. Here we go the ACS way, or course

I would say this is the key screen in the entire process. Here we prompt the developer to provide the ACS namespace theyw ant to use with their iOS application, and the management key we need to modify the namespace settings accordingly. If you are unsure about how to obtain those values, a helpful link points to a document which will briefly explain how to navigate the ACS portal to get those.

In this wizard we try to strike a balance between showing you the power of the services we use and keeping the experience simple. As we did for the WP7 toolkit, here we apply some defaults (Google, yahoo and live id as identity providers, pass-through rules for all) that will show how ACS works without offering too many knobs and levers to operate. If you are unhappy with the defaults, you can always go directly to the portal and modify the settings accordingly. For example you may add a Facebook app as identity provider, and that will show up automatically in the phone application without any changes to the code.

The final screen of the wizard informs you that it has enough info to start the automatic configuration process. First it will generate a ServiceConfiguration.cscfg file, which you’ll use for configuring the Windows Azure backend (your cloudready package) via the portal. Then the wizard will reach out directly to the ACS management endpoint, and will add all the settings as specified.

As soon as you hit Save the wizard will ask you for amlocation for the cscfg file, then it will contact ACS and show you a bar as it progresses thru the configuration. Pretty neat!

Above you can see the generated ServiceConfiguration.cscfg. Of course the entire point of generating the file is so that you don’t have to worry about the details, but if you are curious you can poke around. You’ll mainly find the connection strings for the Windows Azure storage and the settings for driving the interaction with ACS.

All you need to do is to navigate (via the Windows Azure management portal) to the hosted service you are using for your backend, hit Configure and paste in the autogenerated ServiceConfiguration.cscfg.

The next step in the screencast shows how to run the sample application, already properly configured, in Xcode. If you hit the play button, you’ll be greeted by the screen which which I opened the post.

The rest is business as usual: the application follows the same pattern as the ACS phone sample and labs: an initial selection driven by browser based sign in protocols to obtain and cache the token from ACS (a SWT) and subsequent web service calls secured via OAuth. Below a Windows Live ID prompt, followed by the first screen of the app upon successful authentication.

 

Well, that’s it folks! I know that Wade and the gang will keep an eye on the GitHub repository: play with the code, let them know what you like and what you don’t like, branch the code and add the improvements you want, go crazy!