<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <p><br>
    </p>
    <div class="moz-cite-prefix">On 10/5/24 3:03 AM, Paul B. Henson
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:ZwDkscTZhidHCs8m@mutt.cpp.edu"><br>
      <pre class="moz-quote-pre" wrap="">
Ah, you're saying that the client passed a Host header of
"connectcpp.atriumcampus.com" or "streaming.cpp.edu" in the request, and
that filtered down to the idp?</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Yes. Either that, or else something else on the the local IdP
      machine(s) is causing the inbound request to be seen as coming
      from that domain/URL.</p>
    <p>Having some web server logs to absolutely confirm what is
      actually inbound to the IdP on the wire - including headers -
      would be useful.</p>
    <p>Regarding the latter case, is there anything in the local
      /etc/hosts of the IdP for those domains?  What about DNS from the
      IdP machine, esp reverse lookups for the IdP's IP addr? (From the
      machine itself is important, if you have different internal vs
      external DNS, like my env does.)<br>
    </p>
    <p>The latter is just an outside possibility, but the way the IdP
      code works is:<br>
      1) the request URL is obtained as a string from
      HttpServletRequest#getRequestURL().toString() (which should
      reflect Host header)<br>
      2) that string is ultimately passed into the ctor of
      java.net.URL.URL(String), which is used in the URL
      canonicalization process.<br>
      3) the hostname in the canonicalized URL string is going to come
      from URL#getHost()<br>
    </p>
    <p>So I suppose it is very remotely possible that there is some
      heretofore unseen issue (unseen in 15+ years).  Or maybe a change
      in Java, since both HttpServletRequest and URL are JDK-supplied
      classes.  What vendor and version of Java is the IdP running?</p>
    <p>But it would still have to be interacting with something on the
      IdP (e.g. /etc/hosts) and/or in DNS, I think.<br>
    </p>
    <p>Setting that possibility aside and assuming that those domains
      really are in the Host header being sent inbound, then...:<br>
    </p>
    <p><br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:ZwDkscTZhidHCs8m@mutt.cpp.edu">
      <pre class="moz-quote-pre" wrap="">

Hmm. That doesn't make any sense, there is no virtual hosting on these
boxes, they're dedicated to the idp. The box will accept whatever random
host header:

        curl -k -v --connect-to bogus.crap:443:idp.cpp.edu:443 <a class="moz-txt-link-freetext" href="https://bogus.crap/idp/shibboleth">https://bogus.crap/idp/shibboleth</a>

but it still gets passed to the idp servlet.</pre>
    </blockquote>
    <p><br>
    </p>
    <p>Yes, if Jetty is like httpd, and I believe it is, it's not doing
      any name-based vhosting by default, so as long as the request
      winds up on the IP+port on which the IdP is listening, it's going
      to get processed.  And then the HttpServletRequest is going to
      report the request URL based on the Host header, etc.  The
      security handler is obtaining this value with
      HttpServletRequest#getRequestURL().toString().<br>
    </p>
    <p><br>
    </p>
    <blockquote type="cite" cite="mid:ZwDkscTZhidHCs8m@mutt.cpp.edu">
      <pre class="moz-quote-pre" wrap="">

There definitely isn't anything in DNS that would result in an end user
browser connecting to the ip address of idp.cpp.edu based on the name of
some random SP 8-/. In both examples the user agent was a regular
browser, unless somebody was lying about it. They'd have to be
overriding DNS on their local host or using a MITM proxy to futz with
the request in progress. But why?</pre>
    </blockquote>
    <p><br>
    </p>
    <p>I truly have no idea.  Since sounds like those 2 domains are
      actually SPs(!), then this would fall into the category of
      "weird".  Somewhere, somehow there are local hosts files,
      redirects and/or other config that is causing it to happen.<br>
    </p>
    <p>Based on the SAML request Destination the SP(s) emitting the
      AuthnRequest must be correctly attempting to send the request to
      idp.cpp.edu.  And unless the SP is completely broken, that would
      also be the target of the Redirect or POST binding it emits.</p>
    <p>So in order to produce what you're seeing, the weirdness would
      have to be something like this:<br>
      1) somehow the Redirect/POST from the browser is getting
      redirected to connectcpp.atriumcampus.com or streaming.cpp.edu.<br>
      2) from the browser perspective, those domains are getting
      resolved to the same IP as idp.cpp.edu</p>
    <p>How? Why?  I have no idea.<br>
    </p>
    <br>
  </body>
</html>