HTTPS sites behind HTTP load balancers and OpenIdConnect middleware

[gzak]

I've encountered an interesting catch-22 case today with our current setup. We have an app which is hosted on a secured domain, e.g. https://mysite.com. Requests to that domain actually hit a load balancer, which forwards the request to the proper service but via plain-old HTTP.

We've registered our site with Thinktecture's Identity Server to use an HTTPS redirect url for the OpenId callback path. However, the middleware generates the redirect_url parameter based on the current request protocol, which in our case is HTTP since it's coming from the load balancer, and therefore fails. Currently, it fails because http: is not the registered callback url for the app, but even if we registered http: instead, the request would fail anyway because it's not secured.

I heard that ID Server itself supports a load balancer setting (haven't looked into it yet myself), so I'm wondering if the client-side middleware is simply lacking a corresponding feature.

Alternatively, is there a best practice around load balancers which we're not following which obviates the need for explicit middleware support? Or how would you recommend we proceed?

[Tratcher]

Does your load balancer set the x-forwarded-proto header to tell you what the original scheme was? If so you can use this: https://github.com/aspnet/BasicMiddleware/blob/dev/samples/HttpOverridesSample/Startup.cs#L13

This should update HttpRequest.Scheme so your link generation works correctly.

[gzak]

Is this available in RC1? That's what we're currently using.

[gzak]

Never mind, found it!

The current names start with OverrideHeaders instead of ForwardedHeaders. Let me see if this works.

[gzak]

One more question: I looked through the UseIISPlatformHandler logic, and it appears to look for the scheme and ip and things of that nature, so should I register it before or after the forwarders? Or what's the effect one way or the other?

[Tratcher]

UseIISPlatformHandler had some duplicated logic from OverrideHeaders (since consolidated in RC2). Does your site look like this?
Load balancer -> IIS -> Kestrel

Does your load balancer supply x-forwarded-proto headers? There's a known issue with HttpPlatformHandler 1.2 where it will overwrite the x-forwarded-proto rather than append to it (since fixed in AspNetCoreModule for RC2).

If this all gets too complicated and you know you're always running on an https connection externally, the simplest workaround is to add the following before you auth middleware:

app.Use((context, next) =>
{
  context.Request.Scheme = "https";
  return next();
});

[gzak]

Does your site look like this?

Yes

Does your load balancer supply x-forwarded-proto headers?

Not sure, but I'll find out experimentally shortly.

There's a known issue with HttpPlatformHandler 1.2...

Is that the version I'm getting if I run on the RC1 release?

Thanks for the bear-bones workaround, I'll fall back to that if all else fails.

[gzak]

Well, it turns out our load balancer does not add the x-forwarded-proto header, but the fallback workaround works fine. One thing worth noting is that it had to come after the call to UseIISPlatformHandler.