IIS 7 and Above
URL Rewrite Module
Conditional host name possible?
Last post May 01, 2021 10:44 PM by JackieMaus
Apr 11, 2021 02:16 PM|MacGydver|LINK
I am not an IIS proxy expert but am in a crunch to get something done. We have an IIS Proxy that fronts a couple of application servers in a farm:
Accessing https://proxy.company1.com/app works fine. We have an oAuth module that generates the redirect_uri based on the hostname and the app server detects
https://proxy.company1.com properly as it seems IIS Proxy is instructing correctly.
We have a customer that utilizes our server by with their own URL. They use an apache host, also with SSL:
https://proxy.internal.com/app -> farm
When the redirect URI is generated on the app server, it still uses
https://proxy.internal.com/app I could statically tell the application to use
https://proxy.customercompany.com/app but then it would break those using
We need it to work both ways and I am not well versed on conditional logic for IIS Proxy/ARR. Has anyone done something similar that can provide guidance? What I believe is the psuedo logic needed would be something like:
If X-Forwarded-Host, X-Forwarded-Scheme has values, use those for host/scheme values, otherwise use self hostname as values?
I tried having customer use ProxyPreserveHost in their setup but it seems when you are doing SSL to SSL, preserving the host breaks the SSL handshake so I am hoping to solve this as the IIS ARR level.
Thank you for any assistance.
May 01, 2021 10:44 PM|JackieMaus|LINK
I'll present my interpretation of what you are trying to do as I am not certain that I completely understand it:
Your customer has an IIS server with a load-balanced Server Farm that is routing https calls to two self-hosted app servers.
This is done with an inbound rewrite rule that looks for a url staring with "app" and then rewrites it to one of the app servers.
The app servers use an OAuth imlplementation that redirects an end-user's browser to a login page and back. When redirected back, the url in the user's browser is
NOTE: There is no clear indication that any outound rewrite rules are in use.
The customer also has an Apache server. The customer has set it up to route https calls to the address used by the IIS server:
This is done with an Apache equivalent to an IIS inbound rewrite rule.
When a user accesses https://proxy.customercompany.com/app and gets to the OAuth login dialog, their browser is redirected to https://proxy.internal.com/app after logging in. That of course is incorrect as the expected return address is
THE DESIRED RESULT:
When a user accesses https://proxy.customercompany.com/app and gets to the OAuth login dialog, their browser is redirected to https://proxy.customercompany.com/app after logging in.
Let me know if my interpretation is correct or not. If it is, then this may be a corrected bug in the OAuth2 proxy implementation: https://github.com/oauth2-proxy/oauth2-proxy/pull/729. The solution would be to update the OAuth2 Proxy code in the app servers.
OAuth as a general concept may require registered trusted endpoints. https://proxy.customercompany.com/app may need whitelisting / registration to even be an option to use for a redirect-back operation.