Wade Wegner

Yesterday I shared all the NuGet packages we’re building to make it easy to build Windows Phone and Windows Azure applications. Today I wanted to share how easy it is to build a Windows Phone application that leverages the Windows Azure Access Control service.

The Phone.Identity.AccessControl.BasePage NuGet package includes a control for Window Phone that allows your phone applications to outsource user authentication to the Windows Azure Access Control service (ACS). This service enables your users to login by reusing their existing accounts from identity providers such as Windows Live ID, Google, Yahoo, Facebook, and even Active Directory. If you want to know more about ACS you can take a look at the dedicated hands-on labs in the Windows Azure Platform Training Course.

Using this NuGet package and the included control for ACS in your Windows Phone applications takes care of all the runtime interactions with ACS. Additionally, this package provides a base login page that uses the control and is easy to setup in your phone application. All that is left for you to do is to configure your ACS namespace via the management portal (i.e. specifying your preferences such as the identity providers you want to enable in your application) and integrate the login page into your existing Windows Phone application.

For more information on setting up ACS take a look at the resources at http://acs.codeplex.com/

To help simplify the process below, I’m making the assumption you already have ACS setup and configured. I’ll be using the following values in the below sample (no guarantee that they’ll be available when you read this post but I’ll do my best):

• namespace: watwindowsphone
• realm: uri:watwindowsphone

Without further ado, here are the steps to build a Windows Phone application that outsources authentication to ACS:

1. Create a new Windows Phone OS 7.1 application.
   
2. From the Package Manager Console type the following to install the ACS base login page NuGet package for Windows Phone: Install-Package Phone.Identity.AccessControl.BasePage
   
3. Update the AccessControlResources.xaml resources file to use your ACS namespace and the realm you have configured.

       <system:String x:Key="acsNamespace">watwindowsphone</system:String>
       <system:String x:Key="realm">uri:watwindowsphone</system:String>
   

4. Update the WMAppManifest.xml file so that the default page is the LoginPage.xaml. This way the user will come to the login page before the MainPage.xaml.
5. Update the LoginPage.xaml.cs so that the user is navigated to the MainPage.xaml upon successfully logging into the application. Make sure to update Line 23 and Line 33.

    this.NavigationService.Navigate(new Uri("/MainPage.xaml", UriKind.Relative));

6. Let’s display some information from the Simple Web Token. Add a TextBlock control to the MainPage.xaml page. 

       <!--ContentPanel - place additional content here-->
       <Grid x:Name="ContentPanel" Grid.Row="1" Margin="12,0,12,0">
           <TextBlock Name="DisplayLoginInfo" />
       </Grid>
   

7. Add a Loaded event for the MainPage.xaml. In this event you’ll want to load the simpleWebTokenStore out of the application resources. You can then use it to grab resources like the name identifier or various other claim types (like Name). Finish by updating the DisplayLoginInfotextblock.

       using Microsoft.WindowsAzure.Samples.Phone.Identity.AccessControl;
   
       ...
   
       var simpleWebTokenStore = Application.Current.Resources["swtStore"]
           as SimpleWebTokenStore;
   
       var userNameIdentifier = simpleWebTokenStore.SimpleWebToken.NameIdentifier;
       var name = simpleWebTokenStore.SimpleWebToken.Claims[ClaimTypes.Name];
   
       this.DisplayLoginInfo.Text =
           "Identifier: " + userNameIdentifier + Environment.NewLine +
           "Name: " + name;

8. Run the application. I’d recommend using Facebook, Google, or Yahoo! for the identity providers, as Live ID does not provide the name claim type in the SWT token.

And that’s it! You can now take advantage of the Identifier claim (and others) in your phone application for many things – tracking users, displaying additional user information, and so forth. Additionally, you can use these claims to authenticate against additional services running in Windows Azure – I’ll cover this token in a future post.

The Phone.Identity.AccessControl.BasePage NuGet package makes it really easy for you to take advantage of the Windows Azure Access Control service within your applications. ACS provides a great way for you to leverage your users existing identity providers when using your application.

I hope this helps!

I love building keynote applications! I had the great fortune to work with John Shewchuk – Technical Fellow at Microsoft – as he demonstrated a vision for how identity in Windows Azure can enable great experiences in Windows 8. I wanted to quickly provide some background on the components of the sample application he showed called Margie’s Travel.

Margie’s Travel is a sample travel application that demonstrates how you can track and manage your trips across multiple Windows 8 machines using a combination of technologies in Windows Azure and Windows 8.

The application is a Metro styled app built on HTML5, CSS, and JavaScript. Additionally, this application was rapidly built by using the templates and samples found in the Windows Azure Toolkit for Windows 8.

When the application is launched, the user needs to login. Rather than creating yet another identity store, or mapping directly to a specific identity provider, Margie’s Travel uses the Windows Azure Access Control Service.

When you click the login button, the application first checks the Windows PasswordVault to see if the credential (which includes the token) exists:

var vault = new Windows.Security.Credentials.PasswordVault();
var cred = vault.retrieve(url, username);

If this exists, the application will login.  If not, the the application calls out to the Access Control Service to get a list of identity providers from which the user can select.

This code is also very simple to write in JavaScript:

var request = new XMLHttpRequest();
request.open("GET", IPSFeedURL("https://ACSNAMESPACE.accesscontrol.windows.net"), false);
request.send(null);
var jsonString = request.responseText;
var jsonlist = ParseIPList(jsonString);

BindJsonToList(jsonlist);

Once the users makes the selection, the Windows Web Authentication Broker invoked. This allows us to use a consistent and secure method for handling authentication. The login page for the selected identity provider is rendered in the broker.

Once the user logs in, the Access Control Service token is return to the Web Auth Broker. The application is able to take the credential and store it into the Windows Web Vault. This gives us a consistent SSO experience so that upon subsequent launches thee user does not need to log in again.

To store the credential, we simply take the various components, create a new PasswordCredential, and add it to the vault.

var cred = new Windows.Security.Credentials.PasswordCredential(
    url,
    username,
    token);
vault.add(cred);

Furthermore, since the Web Broker can synchronize across trusted devices using Windows Live, the token is automatically synchronized to any trusted device so that you can get SSO across multiple devices.

Once logged in, the application will call out to additional Web services in Windows Azure (like the GetTravelerInfo() method) so that we can validate the users credentials before returning the results.

In addition, this token can be used to call out to additional services in Windows Azure, to get rich pictures from Bing, specific data from the Windows Azure DataMarket and Wolfram Alpha, and even weather information.

All of this is made possible by unique features and capabilities provided by Windows Azure and Windows 8.

If you want to give this a try, and learn more about how all this works, download the Windows Azure Toolkit for Windows 8. Additionally, take a look at posts by Nick Harris and Vittorio Bertocci.

I hope this helps!

Today we released an update to our Windows Azure Toolkit for iOS that provides some significant enhancements – in particular, we now provide support for using the Windows Azure Access Control Server (ACS) from an iOS application.  You can get all the bits here:

• (updated) watoolkitios-lib
• (updated) watoolkitios-samples
• (updated) watoolkitios-doc
• (new) watoolkitios-configutility
• (new) cloudreadypackages

We first released this toolkit on May 6th, and since then we’ve released two minor updates and even accepted a merge request from the community.  This toolkit has been a real pleasure to work on.  Not only has it been to break out of the traditional Microsoft stack and learn about new languages and environments, but it’s also been great to introduce a lot of Objective-C and iOS developers to the power of Windows Azure.

There are three key aspects to version 1.2 of the iOS toolkit:

1. Cloud Ready Packages for Devices
2. Configuration Tool
3. Support for ACS

These three pieces are incredibly important when trying to develop iOS applications that use Windows Azure; consequently, let me try and explain each of these components and how they help to make development easier.

Cloud Ready Packages for Devices

One of the biggest challenges when using Windows Azure for an iOS developer today is the inability to create a package that can be deployed to Windows Azure.  To make this easier, we have pre-built four Cloud Ready Packages for Devices so that you – the iOS developer – don’t have to setup Windows 7 and run CSPACK.  Instead, you simply have to download the most appropriate cloud ready package, update the .CSCFG file, then deploy through the Windows Azure Portal.

We have four “flavors” of the Cloud Ready Packages:

• ACS + APNS – this version allows you to use the Access Control Service and register your certificate for the Apple Push Notification Service
• ACS – this version allows you to use the Access Control Service
• Membership + APNS – this version allows you to use a simple membership store in Windows Azure table storage for users and register your certificate for the Apple Push Notification Service
• Membership – this version allows you to use a simple membership store in Windows Azure table storage for users

For more information on how to use and deploy these packages, take a look at this video on deploying the Cloud Ready Packages for Devices.

Configuration Tool

Along with the CSPKG you need a CSCFG to deploy your application to Windows Azure.  The CSCFG file is an xml document that helps to describe elements of your application to Windows Azure so that it is able to correctly run your application.

In Visual Studio we have tools that make it easy to update the CSCFG file without having to open up the XML, but of course you cannot do this on a Mac.  To make this easier, we created a tool that you can use on the Mac to walkthrough and generate the CSCFG file with all the appropriate details.  Once created, you can use this CSCFG file along with the downloaded CSPKG file to deploy your application.

In addition to creating the CSCFG file, the configuration tool will also updated ACS with all the appropriate settings so that you can build & run your application quickly.  For all the details, please take a look at Vittorio Bertocci’s post on Using the Windows Azure Access Control Service in iOS Applications.

Support for ACS

Everything I’ve described above is designed to make it easier for an iOS developer to quickly and easily use the Access Control Service.  To use the library for authenticating to ACS, it’s really quite simple:

NSLog(@"Intializing the Access Control Client...");
WACloudAccessControlClient *acsClient = [WACloudAccessControlClient accessControlClientForNamespace:@"iostest-walkthrough" realm:@"uri:wazmobiletoolkit"];

[acsClient showInViewController:self.viewController allowsClose:NO withCompletionHandler:^(BOOL authenticated) {
    if (!authenticated)
    {
         NSLog(@"Error authenticating");
    }
    else
    {
         NSLog(@"Creating the authentication token...");
         WACloudAccessToken *token = [WACloudAccessControlClient sharedToken];
         /* Do something with the token here! */
    }
}];

I’ll post more walkthroughs and documentation shortly.

As always, please let me know what you think of the release!  Your feedback is important to us, especially as it pertains to prioritizing future features and capabilities.