Headsup: Brace for Changes in the Windows Azure Active Directory Developer Preview

If you are already using the developer preview of Windows Azure Active Directory, today we published a list of upcoming breaking changes you need to be aware of if you want your code to keep working. If you are not using Windows Azure Active Directory yet, what are you doing here? Go get it! You’ll like it, I guarantee it

The list is nicely detailed, hence there’s no point repeating it here; please make sure you read it carefully. Rather, I’ll try to connect some of the dots for you in term of what you have to change in your apps to accommodate the changes.

Changes in the Web SSO Settings

We are introducing some changes in the endpoints you use for integrating Web sign on from the directory to your Web application. If you are using WIF, that largely means that once the changes will be rolled in production you will have to apply the following change in the web.config of your existing apps:

   1:  <system.identityModel.services>

   2:   <federationConfiguration>

   3:     <cookieHandler requireSsl="false" />

   4:        <wsFederation passiveRedirectEnabled="true"

   5:  

              "https://login.windows.net/929bfe53-8d2d-4d9e-a94d-dd3c121183b4/v2/wsfed"

   6:  realm="http://myhost/myapp"

   7:  reply="https://localhost:44336/" requireHttps="false" />

   8:    </federationConfiguration>

   9:  </system.identityModel.services>

Got it? This is a pretty simple, but important, usability improvement. That string does show up in the browser’s address bar at authentication time, and while the GUID used for the tenant ID is still somewhat scary, “login.windows.net” should be much friendlier than what we had before and be more suggestive of the function it serves.

That’s for applications that are already configured to do Web SSO with Windows Azure AD. What if you want to configure an app that does not have any previous settings to start from? There’s something to be said about that situation, too. The metadata endpoint format will also change to accommodate the new hostname: that means that in order to establish a trust relationship with the tenant described by the snippet above you’d have to point the Identity and Access Tools for VS2012 to

https://login.windows.net/929bfe53-8d2d-4d9e-a94d-dd3c121183b4/federationmetadata/2007-06/federationmetadata.xml

Nothing especially bad, right?

Changes in the Claims Issued by Windows Azure AD

We are also changing the set of claims you’ll receive from Windows Azure AD. This is mostly a consolidation for eliminating redundant or unneeded values, and for providing extra info that will come in handy.
The change list distinguishes between changes that will take place in SAML tokens, and changes that you’ll see in JWT tokens issued when authenticating users through rich client flows (like the one shown here).

I started writing a consolidated explanation of what those claims mean in practice, but mid-flight I realized that I need to do a bit more digging before doing so. Hence, please give the doc a good read and let us know if you have any questions!