We recently solved a Shibboleth problem for a customer who had Microsoft IIS, with multiple Shibbolized web sites using lazy sessions, and we wanted to share the solution.
- Windows IIS with standard Shibboleth package
- Multiple sites with different virtual SP’s configured using the RequestMap and application override functions (see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPRequestMapper)
The system worked correctly when Shibboleth was activated by browsing to the protected path in the RequestMap. The application needed to support multiple login methods, so the lazy session initiation was used when Shibboleth requested at the beginning of the user session (see https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPSessionCreationParameters)
This session initiator for the SP that was configured as the override would form the SAML request as if it was the default application.
The original configuration in the RequestMapper:
<Host name="pc2.idmintegration.com"> <Path name="Default/sso" authType="shibboleth" requireSession="true" applicationId="access"/> </Host>
The updated configuration in the RequestMapper:
<Host name="pc2.idmintegration.com" applicationId="access"> <Path name="Default/sso" authType="shibboleth" requireSession="true" applicationId="access"/> </Host>
We found through the Native.log file that the ISAPI module was not using the correct applicationID for the requests outside the path in the Path statement. Adding the applicaitonID at the host level with no other requirements for a Shib session let the application override work. This allowed the site to work without forcing Shibboleth auth, but allowed the ISAPI module to relate the Session call to the correct application ID.
We suspect that the combination of Microsoft IIS with multiple Shibbolized websites, using lazy session initiation is rare, but since we couldn’t find any documentation on this specific setup, we thought we’d share our solution.