Ex: SAML message intended destination endpoint did not match the recipient endpoint

[Brent Putman]

On 10/5/24 3:03 AM, Paul B. Henson wrote:
>
> 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?


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.

Having some web server logs to absolutely confirm what is actually 
inbound to the IdP on the wire - including headers - would be useful.

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

The latter is just an outside possibility, but the way the IdP code 
works is:
1) the request URL is obtained as a string from 
HttpServletRequest#getRequestURL().toString() (which should reflect 
Host header)
2) that string is ultimately passed into the ctor of 
java.net.URL.URL(String), which is used in the URL canonicalization 
process.
3) the hostname in the canonicalized URL string is going to come from 
URL#getHost()

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?

But it would still have to be interacting with something on the IdP 
(e.g. /etc/hosts) and/or in DNS, I think.

Setting that possibility aside and assuming that those domains really 
are in the Host header being sent inbound, then...:



>
> 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:443https://bogus.crap/idp/shibboleth
>
> but it still gets passed to the idp servlet.


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().


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


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.

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.

So in order to produce what you're seeing, the weirdness would have to 
be something like this:
1) somehow the Redirect/POST from the browser is getting redirected to 
connectcpp.atriumcampus.com or streaming.cpp.edu.
2) from the browser perspective, those domains are getting resolved to 
the same IP as idp.cpp.edu

How? Why?  I have no idea.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20241005/6641fae9/attachment.htm>