Blog
RSS feed

Windows Azure Integration with Windows Live ID, Active Directory and OpenID

Hi everyone, George Moore and Neelamadhaba Mahaptro here from the Live Services team. For the past several months the Live Framework and Windows Live ID teams have been working together to enable turnkey integration of Windows Azure with Windows Live ID, Active Directory and OpenID. This work shipped as a part of the CTP releases at PDC2008. The integration is made possible through the combination of the Azure Services Developer Portal, Microsoft Federation Gateway, and the Microsoft Services Connector.

This integration enables the following identity scenarios "out of the box" with Windows Azure:

  • Easily incorporate Live services into Windows Azure applications
  • Data portability: access data from Windows Azure that belongs to Live users (contacts, Mesh data, etc)
  • Accept hundreds of millions of Windows Live IDs into Windows Azure apps - users don't need a new ID
  • Accept federated business users into Windows Azure applications:
    • Microsoft has a turnkey solution for Active Directory-based businesses
    • Non-Active Directory businesses can federate with a little extra work
  • Accept federated identities via OpenID providers

In addition, the Windows Live Tools and the Cloud Computing Tools for Visual Studio were designed to provide seamless integration into this overall process, including the auto-provisioning of the necessary identity bindings into the ASP.NET controls.

This blog post visually walks through the overall developer lifecycle experience in adding Windows Live ID or Active Directory authentication into a Windows Azure application, followed by the end-user experience in consuming such an application. For a complete demo for how to set up the Federation Gateway and the Services Connector, please watch the Connecting Active Directory to Microsoft Services presentation from the PDC.

Developer Life Cycle Experience

Step 1: Developer visits the Azure Services Developer Portal to create their new Azure project.

Developer presses "New Project" in the upper left, and then selects "Hosted Services for Windows Azure":

Step 2: Developer selects a label for their project, along with an optional description, and presses "Next":

Step 3: Developer selects a vanity DNS name of their new service which will appear within the cloudapp.net domain for Windows Azure:

Step 4: The portal now automatically creates an empty hosting project, registers the new domain name with LiveDNS, and creates the necessary identity bindings for later connectivity to Windows Live ID. These bindings include the Application ID, Secret Key and Return URL.

The developer was not required to manually enter these identity bindings - they were created and registered automatically by the portal into the Windows Live ID service, and are now ready for later use:

Step 5: Now the developer must author and provision their application. They launch Visual Studio and select File: New Project: Blank Cloud Service:

Step 6: Add a new Web Role to the project:

Step 7: Choose Windows Live for the new template:

Step 8: The developer is then given a blank designer page within Visual Studio. The Windows Live service controls for ASP.NET appear on the left (MessengerChat, IDLoginView, IDLoginStatus, Contacts, Silverlight Streaming and Virtual Earth).

These have all been modified to work with the Windows Azure trust model:

Step 9: Developer drags and drops the IDLoginStatus ASP.NET control for Windows Live ID web authentication onto their web page. Note the Visual Studio smart tag task automation item entitled "Configure Application ID":

Step 10: When the developer selects the "Configure Application ID" menu item for this ASP.NET control, we automatically start a Trident browser window within VS which points to the Azure Services Developer Portal.

This requires a developer login to retrieve the identity bindings which were automatically created in Step 4.

Step 11: The portal, running within the Trident window within Visual Studio, presents a simplified list of all previously created Azure projects. Windows Azure projects are shown with the Hosting Service icon, while Live Services projects are shown with the Live icon.

When the developer selects the correct project and presses "Ok", the portal transmits the necessary Application ID and the Secret Key to Visual Studio. This creates the three-way binding between the ASP.NET control, the Windows Azure DNS name, and the Microsoft Federation Gateway:

Step 12: The developer then compiles the project in Visual Studio (via the Windows Azure SDK) and uploads it to Windows Azure (via the portal).

Once the application has been promoted to Production by the developer, the application is then running under the domain name registered for the identity bindings and will be able to fully participate in any of the Windows Live ID identity services:

End User Authentication Experience using Active Directory

Step 1: The end user visits a website hosted by Windows Azure configured in the steps above. The end user presses the "Sign In" link to authenticate this site against their corporate Active Directory credentials:

Step 2(a): When the "Sign In" button is pressed, the user is taken to the standard Windows Live ID sign-in page.

In this Step 2(a) example, Mary has never before signed into this site using her Active Directory credentials. Because the "fabrikam2.com" domain has been previously registered and administered by the Microsoft Services Connector, Mary is given the opportunity to select "Partner ID" in the Windows Live ID menu, type her email address, and then press the "Go there" button. Windows Live ID knows the location of the Fabrikam AD authentication page via MSC:

Step 2(b): In alternative Step 2(b), Mary had previously authenticated to the Fabrikam site, and so Windows Live ID remembers her ID. When she presses her name, she is immediately taken to the Fabrikam corporate site for authentication:

Step 3: Redirection occurs to Fabrikam's Active Directory authentication page on their corporate network.

Mary types her AD credentials:

Step 4: Once the Fabrikam site has properly validated Mary's credentials, a redirection happens back to the original Windows Azure-hosted site with the unique user ID provided. This site can now directly utilize Fabrikam corporate resources via Mary's credentials using the Federation Gateway:

image

Questions? Comments?

If you have any questions or comments, join us in the Windows Azure forum.

Published Wednesday, November 12, 2008 12:08 PM by george.moore