...
With IIS, the first thing to do is to check the Windows Event Log. If you access a site with the filter installed, you should get event log messages saying that the filter initialized. If so, the filter is running, and there's a decent chance permissions are ok. If not, I'd start by making sure that the anonymous IIS user (IUSR_<machine>) has read access the \opt\shibboleth-sp tree. There may be other accounts that need access also, if you have ASP.NET AppPool identities configured.
You should also make sure those accounts can write to the \opt\shibboleth-sp\var\log\shibboleth folder. Otherwise you won't get a native.log file created. If that file's there, you should see additional information about the health of the filter.
...
The rest of the protection trickery is in the <RequestMapper>. If you did all the above, but it's still not triggering for you, you've got something wrong in the map. Make sure you have the requireSession="true" attribute placed into the right <Host> or <Path> element for your choice of host or directory names.
...
If you're relying on the <RequestMapper> instead, then you'll run into issues based on server name configuration details. The Apache ServerName command MUST be set to match what you put in the map's <Host> element and you'll need to make sure UseCanonicalName On is set. But additionally you'll need to get the module running for those requests by globally activating the module for those resources, using this kind of approach:
...