Non-default handler URL fails with IIS 7 module
Description
Environment
Shibboleth SP V3.0.4
Windows Server 2012 R2
IIS 8.5
Activity
Scott Cantor March 26, 2019 at 12:07 AM
Released in 3.0.4.1 service release of Windows installers, posted now. The only file changed is the iis7_shib.dll module.
Scott Cantor March 25, 2019 at 9:18 PM
This is killing me with all the questions, and apparently enough masochism with people using overrides that we need to get this fix out, so I will expedite the basic fix in a service release of the installer.
I'll open a separate bug on the handlerSSL bug and the larger issue of whether any of the DoHandler logic in the module is still viable.
Scott Cantor March 22, 2019 at 6:09 PM
It's kind of both, not just a veto. It checked the path prefix first and if they don't match, it leaves the SP to decide later. The bug I fixed was to allow the SP later to actually run it, which it wasn't doing correctly.
But this bug is in the opposite code path. When it does match, it then runs the handler directly, but that check for "match" is only on path, not on the full URL. That means http requests get run as handlers even when handlerSSL is true.
Rod Widdowson March 22, 2019 at 5:42 PM
I need to think this through (which means middle of next week), but doesn't it work the other way? The filter only vetos, and does that based on path.
So if someone says https://../foo and it should have been http://../foo then the short cut will pass it through the rest of the code will behave as it does for every other webserver and refuse further down the pike. The problem comes if the short cut handler refuses https://../bar because it doesn't match but the rest of the code would have.
But I still don't grock why the change @Scott Cantormade to fix this actually works (unless what it does is to stop round-tripping to the browser),
Having said all of which I would be very happy to see this pulled. I don't see that it gains us anything - or if it does I don't know why the other web server plugins don't have an equivalent - or do they, but its don't with configuration?
Since the upgrade of the SP from 2.x to the latest 3.x version, i recognized, that the SP does only accept /SAML2/POST requests on the default location: /Shibboleth.sso.
Configuring other locations with the ApplicationDefaults/Session/handlerURL element leads to a HTTP 404.
Scenario
GET https://my.sp.org/myapp
AuthN request and redirect to IDP
Login @idp
IDP issues SAML Response and redirects correct with:
POST [http://my.sp.org/acs/Shibboleth.sso/SAML2/POST|http://my.sp.org/acs/Shibboleth.soo/SAML2/POST]**
HTTP 404
Config extract of a config, that works with SP 2.x and doesn't anymore with SP 3.0.4:
<InProcess logger="native.logger"> <ISAPI normalizeRequest="true" safeHeaderNames="false" useHeaders="true"> <Site id="1" name="my.sp.org"/> </ISAPI> </InProcess><RequestMapper type="Native"> <RequestMap encoding="URL" applicationId="default"> <Host name="my.sp.org"> <Path name="myapp" authType="shibboleth" requireSession="true" /> <Path name="acs" /> </Host> </RequestMap> </RequestMapper><ApplicationDefaults entityID="https://mysp.org/sp/shibboleth" REMOTE_USER="eppn subject-id pairwise-id persistent-id" cipherSuites="DEFAULT:!EXP:!LOW:!aNULL:!eNULL:!DES:!IDEA:!SEED:!RC4:!3DES:!kRSA:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1"> <Sessions relayState="ss:mem" cookieProps="https" handlerSSL="true" handlerURL="acs/Shibboleth.sso" checkAddress="false" timeout="3600" lifetime="28800"> <SSO entityID="https://my.idp.org/idp/shibboleth">SAML2</SSO> <Logout>SAML2 Local</Logout> <LogoutInitiator type="Admin" Location="/Logout/Admin" acl="10.0.8.93 ::1" /> <Handler type="MetadataGenerator" Location="/Metadata" signing="false"/> <Handler type="Status" Location="/Status"/> <Handler type="Session" Location="/Session" showAttributeValues="true"/> <Handler type="DiscoveryFeed" Location="/DiscoFeed"/> </Sessions> <!-- etc ---> </ApplicationDefaults>