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

[Paul B. Henson]

> From: Brent Putman
> Sent: Saturday, October 5, 2024 1:57 PM
> 
> Having some web server logs to absolutely confirm what is actually inbound to
> the IdP on the wire - including headers - would be useful.

Aaaaaand the survey says:

2024-10-06 13:41:22,382 - 20.77.36.136/node05kmsw97xaz6lnfnoiwmla2ck48092 - ERROR [org.opensaml.saml.common.binding.security.impl.ReceivedEndpointSecurityHandler:202] - Message Handler:  SAML message intended destination endpoint https://idp.cpp.edu/idp/profile/SAML2/Redirect/SSO' did not match the recipient endpoint 'https://connectcpp.atriumcampus.com/idp/profile/SAML2/Redirect/SSO'

20.77.36.136 - - [06/Oct/2024:20:41:22 +0000] "GET /idp/profile/SAML2/Redirect/SSO?SAMLRequest=pZLNTsMwEIRfJfI9cRKlbbDaSoUeqFTUqikcuCDH2VBL8Q9eG%2FH4JCmIcikHTrbX%2FmZnR54jV51lq%2BBP%2BgBvAdBHH6rTyMaLBQlOM8NRItNcATIvWLV62LI8SZl1xhthOnKBXCc4IjgvjSbRZr0gL3V9U7RpU2QlpHUGs9nNpJyWmeBtmmetKKAoy0lTCFGQ6Akc9uSC9EI9jhhgo9Fz7ftSmhdxlsbp9JinrMhYnj%2BTaN1PIzX3I3Xy3iKjVDY2EdYm0IRhT%2FshWtkBHTzm9ACNdCA8raodiVbfdu%2BMxqDAVeDepYDHw%2FZHUBite2LQ5N7JoARXNmAijKKIhirThA4Se7J0CIjiec1jLnCsXhEg0f4r41upG6lfr8dbnx8huz8e9%2FF%2BVx3Jcj40Y2NcbvkPzwo8b7jnf1me08uG59PvD7b8BA%3D%3D&RelayState=https%3A%2F%2Fconnectcpp.atriumcampus.com%2Flogin.php%3Fcid%3D389%26wason%3D%2Fvirtualcardnew.php HTTP/1.1" 400 5415 "https://connectcpp.atriumcampus.com/login.php?cid=389&wason=/virtualcardnew.php" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0.0.0 Safari/537.36" connectcpp.atriumcampus.com

It seems some client is indeed providing the wrong host header 8-/.

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

Interestingly, all of these failures since I enabled the extra logging come from a single IP address, 20.77.36.136, which is part of the Microsoft Azure cloud public address space...

Dunno. In the end I think somebody somewhere is doing something stupid, but it has nothing to do with jetty or the idp.

I guess I could set it up to reject invalid host headers, although various health checks and load balancer stuff talk to it using the IP address instead of the DNS name so I'd have to include those as well <sigh>.

I already recently had to set it up to reject requests based on user agent since the stupid "blackboard ally - accessibility checker" web crawler evidently intentionally ignores robots.txt and kept trying to load SSO links :(. 

Grumble.

Thanks for the internal details while I was poking at it…