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?)

9
  • 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, 2018 at 10:46
  • Ahh and since it is ASP.NET Core 2, the relative URL should be fine.
    – juunas
    Jan 23, 2018 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, 2018 at 11:03
  • 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, 2018 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, 2019 at 18:40

1 Answer 1

6

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.

1
  • 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, 2019 at 14:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.