Detected spoofed header: HTTP_SHIB_COOKIE_NAME

[Cantor, Scott]

> I'm helping an application admin get Shibboleth working with a Coldfusion app
> running behind IIS. The app has most of the site protected by Shibboleth with
> the exception of a couple of specific paths that are set to not authenticate in the
> request map.

To be clear, that doesn't change the way the SP works. Not requiring a session still leaves the SP enabled and processing. It has to check for an existing session and populate things. If you want the SP off entirely, that takes more than just not requiring a session.

As far as what it's doing, assuming it's current software, I don't know of any reason for the error apart from literally what it's saying, there's an attempt to smuggle the header in, so it's either a subrequest happening improperly inside IIS or a request from inside the application back to itself or something like that. When it flags that, it's not saying there's a bug, but that it couldn't tell either way so it has to err on the side of caution and assume bad intent.

I would fundamentally assume Cold Fusion is simply incompatible with the SP in some way, but it's been years since I was anywhere near it, I'm sure it's changed radically since then. I would have to dig into how the newer IIS module actually deals with all this to see if there are any other code paths likely to trip it.

If the intent is actually to avoid the SP running at all on those paths though, that's possibly a workaround. I'm not sure IIS actually supports that the way Apache does, but I think you can set authType in the RequestMap to something that's not "shibboleth" and it may bypass the SP.

-- Scott