ISAPI Filter Won't Protect One Site

Klingenstein, Nate nklingenstein at calstate.edu
Tue Apr 10 14:22:35 EDT 2018


I'll be precise since there's interest in my failure.

We're trying to bring up a contorted SharePoint server.  One of the modules built into SharePoint was eating SAML assertions before they got to the SP, causing XML tooling exceptions when it tried to parse garbage.  I found the SharePoint module(kinda hard) and disabled it, but that apparently impacted other functionality.

So, I built plan B, which was to run the SP in its own self-contained Site where SharePoint couldn't touch it.  It would protect URL's in both Sites, but it would only consume assertions in the insulated Site.  This worked fine in dev and staging.

The SP integration requires a large amount of glue code written against almost undocumented API's that would be deprecated if Microsoft deprecated anything.  I did not write this code.

Plan B appeared to be partially working on the production nodes.  It just wasn't getting invoked or used on the dedicated Site.  Weirder, If I just went completely through the main SharePoint Site, I was able to get in just fine, assertion and all.  Something in SharePoint was different and that module was gone and not needed.

Anyway, most of the login code existed in both Sites,  but the Sites were pointing to different source directories.  One of the source directories had the login code deployed so poorly that the ISAPI filter couldn't run at all.  Once that source directory got mopped up, Shibboleth was able to protect the second Site and operate as it had in staging.

I really preferred using the single Site as it was apparently working fine, but I was overruled, and here we go.

Again, I hope this helps someone.


More information about the users mailing list