0

My issue

I installed an Azure Application Gateway (AAG) in front of an App Service. Amethystegw and amethysteweb1 repectively. The AAG is on the VNET1.

amethysteweb1 is a real .NET application, not just the default IIS page.

When browsing from the AAG IP, say 20.223.179.174, it redirect on the app service url:

https://amethysteweb1.azurewebsites.net/

So if I set an access restriction on Amethystegw for VNET1 I get a 403:

enter image description here

NOTE: I also tried to set only my public AAG IP

If I activate WAF rules it does not work because everything seem not to pass through AAG.

What I need

What can I do to have a normal behaviour?

Why Backend Health shows 307 code:

enter image description here

Other infos

Yes I tested the app service that works fine.

  • Standard V2 Tier
  • Listener type: Basic
  • No custom domain
  • HTTP (80) port

Rules: enter image description here

Settings:

enter image description here

probe

enter image description here

I successefully tested it.

I read this that is quite similar to my issue:

Azure App Service behind Azure Application Gateway

Frédéric De Lène Mirouze
  • 545
  • 5
  • 25

2 Answers2

0

You need to handle the redirect substitution in the application, at least for .net 5 or 6 we have done it like this in the Startup. That configuration value contains the desired redirect, something like "https://{your url from app gateway}/signin-oidc"

    services.Configure<OpenIdConnectOptions>(OpenIdConnectDefaults.AuthenticationScheme,
     options => {
         Task RedirectToIdentityProvider(RedirectContext ctx) {
             var redirectUri = Configuration.GetValue<string>("AzureAdB2C:RedirectUri");
             if (!string.IsNullOrWhiteSpace(redirectUri)) {
                 ctx.ProtocolMessage.RedirectUri = redirectUri;
             }
             return Task.FromResult(0);
         }

         var previousEvent = options.Events.OnRedirectToIdentityProvider;
         options.Events.OnRedirectToIdentityProvider = (context) => { previousEvent(context); return RedirectToIdentityProvider(context); };
     });
Scott Mildenberger
  • 1,456
  • 8
  • 17
  • sorry, but I don't understand the answer. Why should I do this when it works fine with a pure HTML file? – Frédéric De Lène Mirouze May 19 '22 at 22:48
  • First I will say, I am not great on authentication. What is happening is that the App Service is doing the authentication so the request is coming from the azurewebsites.net url but that url is not publicly accessible so you need the redirect to be to the public url. At least in .Net what I posted is a way to do it. I think you may be able to use Custom Domains in the App Service too but it seems like there was a reason we didn't want to do that. I spent quite a bit of time researching until I found the above which fixes the issue for us. – Scott Mildenberger May 20 '22 at 13:31
0

I found the solutions.

The web apps was a .NET application that forced an HTTP to HTTPS redirection.

I just removed:

app.UseHttpsRedirection();

And it is working now.

Thank you for all those helped me here.

Frédéric De Lène Mirouze
  • 545
  • 5
  • 25
  • I think that is the wrong solution. App services are default SSL enabled. The solution is to use port 443 on the backend settings + use HTTPS protocol on probe. Then the gateway always talks to the app service using HTTPS, not HTTP and you are not sending unencrypted traffic. – jarlef Jun 13 '23 at 13:31