<html>

  <head>

    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">

  </head>

  <body text="#000000" bgcolor="#FFFFFF">

    <p><br>

    </p>

    <br>

    <div class="moz-cite-prefix">On 8/30/17 5:57 PM, O'Dowd, Josh wrote:<br>

    </div>

    <blockquote type="cite"

cite="mid:6C4BCDAB7291C340B9D5C096C70C6C250145BEC603@UMMAIL02.gs.umt.edu">

      <pre wrap="">Thanks Scott,

</pre>

      <blockquote type="cite">

        <pre wrap="">I think it's pretty likely that something out there is accessing a URL on this server that's perhaps improperly being stuck behind the SP and is triggering a redirect that the "something" is handling badly and corrupting before following it to the IdP and then it plays a corrupt request. I don't think there's much beyond that that's knowable, but perhaps getting the user agent from a log entry would be interesting.

</pre>

      </blockquote>

      <pre wrap="">

Well this leads me back to the other really "odd" component in this issue, that the ${idp.remote_addr} is coming in from a subnet (173.252.95.x) that is registered to Facebook, though the "issuer" in the SAMLRequest is definitely one of our local SPs.  I am still trying to get some clarity on why that is, from our sysadmin group, but I am getting crickets instead.  I no longer suspect Facebook is involved, here but all the requests coming in from our other local SPs are from our internal IP ranges.

</pre>

    </blockquote>

    <br>

    That is pretty consistent with Scott's comments then.  Quite

    possibly some automated thingy/widget/bot/whatever at Facebook is

    issuing a request to a resource protected by that SP.  The Facebook

    thingy is getting back the  redirect from the SP, and in trying to

    play the role of the browser-compliant HTTP user agent, it's

    corrupting the request somehow and issuing it to the IdP.   That or

    something similar is probably what's going on.<br>

    <br>

    Or if it's not that, then it's probably something on the network

    between the client HTTP user agent and the IdP that's molesting and

    corrupting the request , like your LB, or some mysterious security

    blackbox (IDS, application firewall, etc) or similar.<br>

    <br>

    As Scott says, the User Agent from the Apache log would be very

    interesting.  If you can get your network/security guys to help you

    trace the full logical path of the request into the IdP from the

    point that it hits your border network device, that would also be

    interesting.<br>

    <br>

    Not sure we can tell you much more than that.<br>

  </body>

</html>