...
This problem is not confined to LazySessions because it's always possible for most attributes to be optional or suppressed at the !IdP, and many kinds of errors can result in valid sessions that appear to be missing attributes. It is, however, easier to reproduce with LazySessions because even the reserved variables like HTTP_SHIB_IDENTITY_PROVIDER can be spoofed.
...
My fix was to add a new unsetHeaderValue option to the ShibbolethXml <Local> element. It's a string valued attribute that can contain a special fixed token value to insert into any header that Shibboleth does not set a real value for, instead of using an empty string. Any CGI variable that's left unset with a real value will just contain the special value you choose. Obviously, it defaults to an empty string, so it works consistently with the older behavior.
...
In theory, it's also possible to claim that when LazySessions are not used and you know that all possible attributes will have values all the time, you're safe. But the latter is almost impossible to actually guarantee. At a minimum, you'd need to force failed queries to abort a new session by setting propagateErrors to true , which is not the default anymore.
...
If after reading this, you come to the conclusion that this all sounds fishy, you're not alone. I believe that as Peter Watkins suggested, the best fix is to eat some CPU and actually search the entire header list for any potential spoofing. This should be simple to implement, except for IIS, so that's the top concern.
%COMMENT%