Enhancements to Windows Azure Active Directory Preview

I’m happy to have the opportunity to share with you another set of enhancements we’ve recently added to our Windows Azure Active Directory Preview. We were excited by the response we got from developers when we launched the Preview in May of this year and over the last few months we’ve worked hard to make it even better based on your feedback and your use of the platform.

An updated version of the Windows Azure Authentication Library which is now 100% managed code.

The ability to federate Directory Tenants with Access Control Namespaces.

Making It Easier to Connect Your Application to Windows Azure Active Directory

When we first launched the Windows Azure Active Directory Preview, we used the Microsoft Online Services Module for Windows PowerShell as the tool administrators used to grant applications access to a company’s Windows Azure AD tenant. While PowerShell is a great approach for some admins, we knew that we also needed to provide a graphical user interface that made it easy for admins to grant your applications access with a few simple clicks.

For developers building applications that need single-sign-on with a single directory tenant, such as an enterprise developer building a web-based line of business application, we’ve developed an extension to Visual Studio that makes it easy to register an application in a directory tenant as part of the development process. This extension is part of the ASP.NET Fall 2012 Update. You can read more about the Windows Azure AD authentication extension part of the update here.

For developers building multi-tenant software-as-a-service applications, we’ve built a web-based experience for your customers to register your application in their directory tenant. You can now give us details about your application, including the access your application requires to the customer’s directory tenant, and your customers can set up single-sign-on and grant your app access to their directory as part of an experience that is integrated with your application’s sign-up process. You can optionally publish your application in to the Windows Azure Marketplace so that customers can discover your application and its benefits.

To help you take advantage of this opportunity, we’ve developed some resources to help get you started:

We would love to get your feedback on this experience, so please provide feedback and questions on our Windows Azure AD forums.

Updates to Web SSO with Windows Azure Active Directory

Addition of SAML 2.0 protocol support for Web SSO

Many of the developers who are participating in the Windows Azure AD developer preview have requested we add support for the SAML 2.0 federation protocol. Many SaaS applications already support SAML 2.0 as a way to sign-in to their applications, and having this support would make it even simpler for these developers to integrate with Windows Azure AD.

We have included the ability for applications to support the single sign-out capability for those using the WS-Federation protocol. We will also be adding sign-out support for SAML 2.0 in a future update.

You can now use a URI as an Application Identifier

When we originally launched the Developer Preview we noted that the Audience field in tokens sent by Windows Azure AD was in SPN format and included both the identifier of the application and the identifier of the tenant, while most other federation systems allow applications to be identified by a URI. We have updated the Preview to enable the use of URIs as application identifiers. For example, instead of receiving a token with Audience value of “spn:<appID_GUID>@<tenantID_GUID>”, it can now simply be “https://www.example.com”.

NOTE: Applications that were registered with Windows Azure AD before we deployed this update will no longer accept sign-in responses and must be updated to continue to function properly. We discuss this in detail in this forum post.

Differential Query: Get Delta Changes to Objects You Care About in the Graph

Part of the power of a Graph API is taking action based on the information in the directory that your application is targeting. With differential query, we’ve given you the ability to listen in to only the information you care about so that your application can be both faster and easier to develop.

A differential query request returns all changes made to specified entities during the time between two consecutive requests. For example, if you make a differential query request an hour after the previous differential query request, only the changes made to objects in the scope of the query during that hour will be returned. This functionality is especially useful when you need to cache directory data in your local application store and keep it in sync with the contents of the directory.

We believe this is a great addition to the platform for application developers, and we have some resources to get you started using this in your application:

The library is now 100% managed. This eliminates the constraints that resulted from the mixed mode nature of the first release. You can now use the library regardless of the “bitness” of your target environment, and the VC runtime is no longer required.

The first WAAL preview concentrated in one single package both client and protected resource features. That led to a number of constraints, such as the dependency on the WIF1.0 runtime and the impossibility of developing with the .NET 4.0 Client Profile. In this refresh we refactored WAAL to work exclusively in the client role, eliminating those restrictions. We will provide the functionality to address the protected resource role in separate components: more about that soon.

The new WAAL bits are already at work in other products! The Windows Azure Active Directory integration features in the ASP.NET Fall 2012 Update use WAAL as part of the setup and publication experience. WAAL is also used in our new sample app to secure calls to the Graph API.

We will soon update the WAAL samples to take advantage of the new managed-only package. At that time, we will retire the current x86- and x64-specific packages.

With the changes in the way in which Windows Azure AD handles application identifiers, you are now able to use directory tenants as identity providers in Windows Azure Access Control service namespaces. This new capability opens up a number of interesting scenarios such as enabling your web application to accept both organizational identities from directory tenants and consumer identities from social providers such as Facebook, Google, Yahoo!, Microsoft accounts or any other OpenID provider. You can find detailed instructions on how to implement the scenario in this post.

Breaking Changes to the Developer Preview

As we respond to your feedback and add or modify features, sometimes we have to make breaking changes to the behavior of the Preview. If you’ve already developed applications using Windows Azure Active Directory or plan to build applications now, please make sure you periodically check the Windows Azure Active Directory Forums for notification of upcoming changes.

We Look Forward to Hearing from You!

And here’s one final note about how to get Windows Azure Active Directory. We’ve had a number of people surprised to find out that every Office 365 customer already has a Windows Azure Active Directory tenant! Windows Azure Active Directory is used by a number of Microsoft cloud services today, and through the developer preview it is possible to extend the usage of these directory tenants to other applications. It’s also possible to obtain a “standalone” directory tenant through our provisioning system.