Azure Active Directory Reply URL not working as expected

Question

I have specified two URLs in my Azure Active Directory website configuration Reply URL. One to redirect to my localhost environment when I am running local code and one to redirect to my Azure hosted website when I am running the prod website. But Azure Active directory seems to be ignoring the setting. It only uses one or the other URL but not both. I saw a link describing the problem and a possible solution but it didn't work for me. The link is:

http://samritchie.net/2013/07/17/azure-ad-single-sign-on-with-multiple-environments-reply-urls/

How do I setup Azure Active Directory to redirect to appropriate environment?

Answer 1

You are not providing details about your implementation, but here is a solution for any case.

You could be using WIF config - which is entirely configuration in your web.cofing, or you could be using OWIN, where configuration is in your Config.Auth.cs file. In either way, the STS of Azure AD will only use the default reply URI, regardless of where the calls are coming from. You have to explicitly set ReplyUrl to instruct the Azure AD to return the user back to one of the registered reply URLs.

WIF solution

When you use WIF, your web config contains following section:

  <system.identityModel.services>
    <federationConfiguration>
      <cookieHandler requireSsl="true" />
      <wsFederation passiveRedirectEnabled="true" 
                    issuer="https://login.windows.net/yourtenant.com/wsfed" 
                    realm="https://yourtenant.com/WebSingleTenant" 
                    requireHttps="true" />
    </federationConfiguration>
  </system.identityModel.services>

which is a bit incomplere! You can add a reply to the wsFederation tag to instruct the Azure AD for the new reply URL:

  <wsFederation passiveRedirectEnabled="true" 
                issuer="https://login.windows.net/yourtenant.com/wsfed" 
                realm="https://yourtenant.com/WebSingleTenant" 
                reply="http://any_registered_url/"
                requireHttps="true" />

Note that here you can only use a registered reply URLs.

To modify reply attribute you can safely use web.config transformations as you do for all your other deployment specific app settings and connection string.

OWIN Solution

When you use OWIN, you would have Startup.Auth.cs file, or your authentication configuration will be directly into your Startup.cs file. It would look something like the following:

    public void ConfigureAuth(IAppBuilder app)
    {
        app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.
            AuthenticationType);

        app.UseCookieAuthentication(new CookieAuthenticationOptions());

        app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = authority,
                PostLogoutRedirectUri = postLogoutRedirectUri
            });
    }

Note the configuration settings for OpenIdConnect authentication. You can add a RedirectUri property to instruct where to redirect the user to:

        app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = authority,
                PostLogoutRedirectUri = postLogoutRedirectUri,
                RedirectUri = "any_registered_redirect_uri"
            });

You can assign RedirectUri to a setting in Web.Config file, which also will you can handle using Web.Config transformations.

Answer 2

For the case of OWIN I have the following configuration solution

            app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = clientId,
                Authority = authority,
                PostLogoutRedirectUri = postLogoutRedirectUri
                #if !DEPLOY
                ,RedirectUri = "https://localhost:44369/"
                #endif
            });

So it uses a local redirect when I am not building for deployment. The project is configured to declare DEPLOY for the version that I am building for deployment. That way, it uses the default redirect URL configured in Azure.