7

We have an ASP Core 2.0 App working nicely with Azure AD on the private network. However, we've been playing around with the Azure Application Gateway, investigating the possibility of allowing access to the app from outside for remote workers etc.

We have registered the app on the Gateway, and, once logged in with Azure AD, the anonymous front page is accessible via ourapp.msappproxy.net. However, when signing in (again?) in the app, the client is redirected back to intervalServer/signin-oidc which fails as it is not accessible externally.

While I doubt this is any part of the solution, I have tried overriding the redirect "CallbackPath": "/signin-oidc", to absolute path ourapp.msappproxy.net/signin-oidc but I can't seem to work out how. Changing the reply URL in Azure Portal doesn't help either (although I doubted it would, this is just for verification right?).

I can't seem to find any guidance on this on this particular scenario, so that would be welcome. Otherwise, I'm left pondering the following:

1, If I could change the redirect to ourapp.msappproxy.net/signin-oidc, would that solve the sign in issue?

2, Do I even need an additional sign in step, or should I be changing the app to accept AzureAppProxyUserSessionCookie or AzureAppProxyAccessCookie? (If that's even an option?)

Mikustykus
  • 300
  • 7
  • 16
  • Have not yet had a chance to try App Gateway, but I can try to explain what is supposed to be configured. The reply URL defined in Azure Portal -> Azure Active Directory -> App Registrations is the URL (or URLs) to which you allow the sending of security tokens for that app. Thus those should match the URL that the user sees in the browser. Your app should use that same URL as the redirect URI. – juunas Jan 23 '18 at 10:46
  • Ahh and since it is ASP.NET Core 2, the relative URL should be fine. – juunas Jan 23 '18 at 10:53
  • So as I understand it, the reply URL is specified in the GET request, which I can change to e.g. `&redirect_uri=https://localhost/44305/test'` via `AppSettings` -> `"CallbackPath": "/test"`. However, I cannot specify an abolute path (which wouldn't be ideal anyway, but just for testing), as I get exception `the path in 'value' must start with '/'.` – Mikustykus Jan 23 '18 at 11:03
  • Yeah since ASP.NET Core will add the hostname of the current request. – juunas Jan 23 '18 at 11:10
  • The trouble is, with the relative URL specified in the app, the client goes from `externalLink` -> `externalLink/Account/Login` -> `internalServer/sign-oidc'`. So the redirect URL being sent is the server address and not the referrer. – Mikustykus Jan 23 '18 at 11:12
  • Pretty interesting. Hopefully something with experience on AG comes with a good answer :) – juunas Jan 23 '18 at 11:20
  • Indeed, it will be a powerful option once figured out :) – Mikustykus Jan 23 '18 at 11:26
  • 2
    Did you figure it out? On the redirect to identityprovider event you can put something like redirectContext.ProtocolMessage.RedirectUri = redirectContext.ProtocolMessage.RedirectUri.Replace("http://", "https://"); Except when the identity provider comex back into sign-oidc then the gateway returns 502 cause of invalid header size in ngix – rfcdejong Nov 23 '18 at 13:12
  • 1
    @rfcdejong Thank you for this! I was forced to come back to the problem after a long time and your suggestion put me one the right path. I elaborate as an answer in case anybody finds it useful in this context... – Mikustykus Jan 29 '19 at 18:40

1 Answers1

5

Thanks to rfcdejong in the comments for putting me on track. In our case I was able use Azure AD with the Azure Application Gateway by overriding OnRedirectToIdentityProvider event and supplying the proxy url in ConfigureServices

services.AddAuthentication(...)
          .AddOpenIdConnect(options =>
         {
           options.ClientId = Configuration["Authentication:AzureAD:ClientId"];
           options.Authority = Configuration["Authentication:AzureAd:Authority"];
           options.CallbackPath = Configuration["Authentication:AzureAd:CallbackPath"];

           if (IsProduction) // So that I can use the original redirect to localhost in development
           {
             Task RedirectToIdentityProvider(RedirectContext ctx)
             {
               ctx.ProtocolMessage.RedirectUri = "https://ourapp.msappproxy.net/signin-oidc";
               return Task.FromResult(0);
             }

             options.Events = new OpenIdConnectEvents
             {
               OnRedirectToIdentityProvider = RedirectToIdentityProvider
             };
           }
          })

The return URI needs to be configured to match for the app in Azure Portal. Users also need to be assigned, but the internal app is now available anywhere without requiring direct access to the server.

Mikustykus
  • 300
  • 7
  • 16
  • You are welcome. We use OnRedirectToIdentityProvider for several reasons. For example to set redirectContext.ProtocolMessage.LoginHint, redirectContext.ProtocolMessage.RedirectUri to force the https scheme and redirectContext.ProtocolMessage.Prompt to select_account. – rfcdejong Jan 30 '19 at 14:03