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

[Paul B. Henson]

> From: Brent Putman <putmanb at georgetown.edu>
> Sent: Wednesday, October 9, 2024 2:55 PM
> 
> Hmm, the front-channel request should be coming from a browser. I guess it
> could be some browser client being NATed from within that cloud env.  Or
> maybe it's something weirder.

Somebody has to be mucking with requests intentionally. I just don't see any scenario where an accidental configuration mistake would do this.

> If you do ever figure the who/how/why of what is going on, I'd be interested to
> know.  This is definitely one of the weirder problem reports I can remember.

Looks like they started popping up in mid-August. Since then, there have been a smattering of them pretty much every day, enough to make it annoying to see it in the daily log report but from a more objective perspective there actually have only been 314 instances of it since then. I would've guessed more but that would've been subjective :).

The requests have come from 19 distinct IP addresses:

     91 20.46.149.159
     35 20.77.36.136
     22 44.192.133.1
     20 20.77.104.74
     17 2a01:239:306:4300:0:0:0:1
     17 2605:7980:0:2153:0:0:0:1
     17 20.217.82.205
     17 185.49.126.47
     17 185.49.126.234
     17 185.118.79.230
      9 5.62.43.167
      9 20.25.195.149
      6 74.249.98.64
      6 159.242.227.91
      6 108.165.237.77
      4 45.134.26.70
      2 4.227.1.204
      1 188.246.226.178
      1 185.137.233.29

Ownership of the IP addresses is distributed between Microsoft and a half dozen other random cloud VPS providers. Definitely not normal end-user browser traffic, although all of the user agents associated with the requests indicate they "came" from normal browsers.

I guess I could complain to Microsoft (likely no point in complaining to the smaller providers), but I don't think they would do anything about it.

There are six different SP's involved:

    249 https://connectcpp.atriumcampus.com/idp/profile/SAML2/Redirect/SSO
     36 https://streaming.cpp.edu/idp/profile/SAML2/Redirect/SSO
     22 https://cpp.levelaccess.net/idp/profile/SAML2/Redirect/SSO
      4 https://35.83.183.112/idp/profile/SAML2/Redirect/SSO
      2 https://52.39.181.198/idp/profile/SAML2/Redirect/SSO
      1 https://cpp.cayuse424.com/idp/profile/SAML2/Redirect/SSO

Four of them are valid SP's configured with our idp, the other two IP address based ones. I dunno, the given IP address is in the Amazon EC2 space.

> But yeah, nothing wrong with your deployment or the IdP code.  In fact, it's
> doing what it should, which is rejecting an invalid request.

That's good, although I would prefer for invalid requesst not to make it that far and show up in the logs, which leads to…

> Fwiw, I always setup my web servers to send requests with a Host header
[...]
> don't know how to do in Jetty, but I imagine there's a way.

	https://jetty.org/docs/jetty/12/operations-guide/deploy/index.html

It appears you can add a virtualHosts definition to the context configuration for the webapp. I assume any paths not matching the listed virtual hosts would go to whatever webapp exists with virtual hosts defined. So if I added virtual hosts for the idp webapp, but not for the root webapp, presumably any /idp URL would give a 404. Which I guess works for me.

I would just either need to include all the variants authorized stuff uses (the lb currently just uses "idp" for health checks, our monitoring system uses the IP address of the backend node) or modify that stuff to use the official name like clients do.

It's not like there isn't enough work to do without random stupid people doing stupid stuff to make more of it <sigh>.

Thanks…