Azure AD Single Sign On with multiple environments (Reply URLs)

As part of an effort to move some internal applications to the cloud (sorry, The Cloud™), I recently went through the process of implementing Azure AD single sign on against our Office365 tenant directory. Working through the excellent MSDN tutorial, I hit the following (where it was describing how to reconfigure Azure AD to deploy your app to production):

Locate the REPLY URL text box, and enter there the address of your target Windows Azure Web Site (for example, https://aadga.windowsazure.net/). That will let Windows Azure AD to return tokens to your Windows Azure Web Site location upon successful authentication (as opposed to the development time location you used earlier in the thread). Once you updated the value, hit SAVE in the command bar at the bottom of the screen.

Wait, what? This appears to imply  Azure AD can’t authenticate an application in more than one environment (eg if you want to run a production & test environment, or, I don’t know, RUN IT LOCALLY) without setting up duplicate Azure applications and making fairly extensive changes to the web.config. Surely there’s a better way?

I noticed that the current version of the Azure management console allows for multiple Reply URL values:
Azure AD Reply URLs

However, just adding another URL didn’t work – the authentication still only redirected to the topmost value.

The key was the \\system.identityModel.services\federationConfiguration\wsFederation@reply attribute in web.config – adding this attribute sent through the reply URL and allowed authentication via the same Azure AD application from multiple environments, with only relatively minor web.config changes.

As the simplest solution, here’s an example Web.Release.config transform – more advanced scenarios could involve scripting xml edits during a build step to automatically configure by environment.

 <system.identityModel.services>
    <federationConfiguration>
      <wsFederation reply="<<your prod url>>" xdt:Transform="SetAttributes" />
    </federationConfiguration>
  </system.identityModel.services>

Running Azure dev storage without an SQLExpress instance

If, like me, you think the SQL Express named instance is a blight on humanity and refuse to sully your dev machine with it, you’ll run into issues trying to start up Azure development storage: “Failed to start Development Storage: the SQL Server instance ‘localhost\SQLExpress’ could not be found”.

The instructions here no longer work with SDK 1.5 – there’s no DevelopmentStorage.exe.config. Instead, you’ll need to run

DSInit /sqlinstance:.

(in “Windows Azure SDK\v1.5\bin\devstore”). This performs magic and your dev storage will start working.

Deploying to Azure from psake – “No snap-ins have been registered”

Cloud hosting really lends itself to continuous deployment approaches – scripted provisioning models and blue/green deployment are well catered for. In the case of Microsoft Azure, the Powershell Cmdlets integrate easily with our psake build scripts.

Unfortunately, the cmdlets are 64 bit only and most of the popular CI servers are java-based and recommend using the 32 bit JVM for a variety of presumably good reasons. This results in 32 bit powershell kicking off and generating the error message “No snap-ins have been registered for Windows PowerShell version 2”.

Following is a modification to the psake.cmd file that ensures the 64 bit version of powershell is called on 64 bit systems:

@echo off
IF EXIST %windir%\sysnative\WindowsPowershell (
%windir%\sysnative\WindowsPowerShell\v1.0\powershell.exe -NoProfile -ExecutionPolicy unrestricted -Command "& '%~dp0\psake.ps1' %*"
) ELSE (
powershell -NoProfile -ExecutionPolicy unrestricted -Command "& '%~dp0\psake.ps1' %*"
)