0

I have a problem configuring my Open Auth ID .net Core 2 application as an App Service behind a Web Application Firewall using a Path based routing.

My application is myapp.azurewebsites.net with a network restriction making it inaccessible from the public internet. I have deployed a WAF in the same VNET and allowed traffic between the WAF and App Service using a Path based route "/Admin*".

The effect is that https://myapp.azurewebsites.net is not internet accessible but https://myWAF/Admin is accessible and maps to the app service.

This setup works fine, but when I introduce Open ID auth to my .net core application the outgoing Location header includes its myapp.azurewebsites.net/signin-oidc as the reply URI.

This doesn't work because the host is not accessible from the internet. I have attempted several approaches;

  • I have added the WAF URL (https://myWAF/Admin/signin-oidc) in the application registration URL in Azure App Registrations to allow AAD to accept the modified URL (as legitimate
  • I have coded app.UseForwardedHeaders (forcing reuse of all X-Forwarded headers) in my startup.cs. This doesn't seem to have any affect on the Location header being sent by my App Service.I presume the WAF is sending X-Forwarded headers, but if it is, the Open Auth ID stack isn't using them.
  • I have coded a header rewrite in the WAF to replace the myapp.azurewebsites.net with the WAF URL. This does replace the URL correctly and allows the callback, but then fails with a Correllation Error (which seems to be a generic Open ID stack error meaning "the nonce does not match". Its possible that the nonce is predicated on the URL being called back to - which in my case changes due to the WAF redirection, but that's a guess).

It seems to me like I should be able to use the X-Forwarded headers in my app to get around the need to code up header re-writes in the WAF, but I can't find an example where this is used successfully to alter the Reply URI being sent out by Open ID.

My question it; is using the X-Forwarded header the correct approach to handling proxies in an OAuth context, or is header-rewriting in the WAF the correct approach ?

I have set

neuro
  • 14,948
  • 3
  • 36
  • 59
PhillipH
  • 6,182
  • 1
  • 15
  • 25

1 Answers1

0

After much investigation I found the following;

  1. WAF does not send the standard X-Forwarded-Host to App Services but sends X-Original-Host instead. Documented here https://feedback.azure.com/forums/217313-networking/suggestions/33657763-add-the-x-forwarded-host-header-to-application-gat

  2. The ForwardedHeaderOptions that ASP.net Core 2 uses in its ForwardedHeaders middleware have an option to replace the expected and supported "X-Forwarded-Host" with an arbitrary other host header name. This behaviour can be triggered as follows to replace the use of the x-Forwarded-Host with the WAF specific X-Original-Host.

    options.ForwardedHostHeaderName = "X-ORIGINAL-HOST";

  3. WAF does not pass the Path of the Path Based Route down the Http Header stack as expected in the PathBase header. This must be added to the Request Headers either in the WAF via a Header Rewrite, or inside the app as follows (in this case the apps Path Route is /Admin);

    app.Use((context, next) => { context.Request.PathBase = new PathString("/Admin"); return next(); });

PhillipH
  • 6,182
  • 1
  • 15
  • 25