We are excited to announce that the IIS.NET Forums are moving to the new Microsoft Q&A experience. Learn more >

Conditional host name possible?RSS

1 reply

Last post May 01, 2021 10:44 PM by JackieMaus

  • Conditional host name possible?

    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:

    https://proxy.company1.com/app ->

          appserver1:80/app

          appserver2:80/app

    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.customercompany.com/app -> 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 https://proxy.internal.com/app

    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.

  • Re: Conditional host name possible?

    May 01, 2021 10:44 PM|JackieMaus|LINK

    Hi MacGydver,

    I'll present my interpretation of what you are trying to do as I am not certain that I completely understand it:

    THE SETUP:
    Your customer has an IIS server with a load-balanced Server Farm that is routing https calls to two self-hosted app servers. 

        https://proxy.internal.com/app --> 
            appserver1:80/app
            appserver2:80/app
            
    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 https://proxy.internal.com/app.

    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:

        https://proxy.customercompany.com/app -->
            https://proxy.internal.com/app
            
    This is done with an Apache equivalent to an IIS inbound rewrite rule. 

    THE PROBLEM:
    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 https://proxy.customercompany.com/app.

    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.