Detected spoofed header: HTTP_SHIB_COOKIE_NAME

[Wessel, Keith]

Thanks, Rod and Scott. Sure enough, setting authtype to an arbitrary undefined variable (authtype="disabled") did the trick. Thank you!

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, May 23, 2023 8:07 AM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Detected spoofed header: HTTP_SHIB_COOKIE_NAME

FWIW, the way the logic works is that it detects up front if it thinks the request is an internal subrequest by checking for the presence of the spoof key value (which is randomly generated most of the time at startup). If it sees that, it considers the request authorized even though all the headers are in place from an earlier request. That's what allows subrequests to run safely.

Assuming not, all it does is check for the ALL_HTTP header value from IIS and uses that to tell if any headers being cleared as under SP control are present and if so, it throws that error.

So one way or another, ALL_HTTP is set and has that header set before the SP started doing work.

Why that is I couldn't say. Offhand, it sounds a bit like the security bug in IIS where the default document module doesn't clear the internal request state before following an internal redirect. But generally the SP will not "fail" in that case because it sees it as a subrequest internally and sees the spoof key.

Maybe one possibility is some kind of weird clustering situation where there are multiple IIS processes, so each one gets its own random spoof key, but the "internal redirect" is crossing between processes.

One option might be to statically set a spoof key.

https://urldefense.com/v3/__https://shibboleth.atlassian.net/wiki/spaces/SP3/pages/2063696243/InProcess__;!!DZ3fjg!5RXgeib_He4SNxa-fMAouWIbE_1ehqOJwBdpqybgauhy5sDgI7C7vGm9dMRX0oW0LNtVUJCYlILSI2tr3JBQ$ 

-- Scott