Wade Wegner

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!

I had the great pleasure of co-authoring an article on application migration to Windows Azure for MSDN Magazine with my friend George Huey, creator of the SQL Azure Migration Wizard.  This article stems from our work helping dozens of customers – both small and big – migrate their existing applications to run in the cloud.

(Ours is the second down on the left.)

While this article is by no means exhaustive, we did try to explain some of the common patterns and scenarios we faced when helping customers migrate their applications into Windows Azure.  I hope you find it valuable.

I was reading through the FAQ document for the Windows Azure platform this evening (what else is there to do on a Sunday night?), and I came across the following:

What is the Windows Azure AppFabric?

With AppFabric, Microsoft is delivering services that enable developers to build and manage composite applications more easily for both server and cloud environments. Windows Azure AppFabric, formerly called “.NET Services”, provides cloud-based services that help developers connect applications and services across Windows Azure, Windows Server and a number of other platforms. Today, it includes Service Bus and Access Control capabilities. Windows Server AppFabric includes caching capabilities and workflow and service management capabilities for applications that run on-premises.

Windows Azure AppFabric is built on Windows Azure, and provides secure connectivity and access control for customers with the need to integrate cloud services with on-premises systems, to perform business-to-business integration or to connect to remote devices.

The Service Bus enables secure connectivity between services and applications across firewall or network boundaries, using a variety of communication patterns. The Access Control Service provides federated, claims-based access control for REST web services. Developers can use these services to build distributed or composite applications and services.

I’ve spent a lot of time with the AppFabric, and believe I understand the intent of the above description.  But what about the rest of you?  If you have, or even if you haven’t, spent time using the AppFabric, how does this description resonate?  Does this help you understand the AppFabric, or are you left confused?  Do you understand it’s place and value in the larger Windows Azure platform?

I implore you to leave some feedback and let me know what you think.  Please, share your thoughts!  How can this be improved?