Shibboleth SP with Windows IIS7 and MVC

[Raymond Lam]

Hi,



I am trying to import Shibboleth in my Windows Server 2008 but it returned a
404 error message.



Server: Windows 2008 Server R2 64-bit with IIS 7

Application Language: ASP.NET MVC 3 Framework 4.0

Shibboleth SP Installation file: shibboleth-sp-2.4.3-win64.msi



1. Installed Shibboleth SP

2. In IIS, I moved the .sso file extension to the top of the list in
"Handler Mappings"

3. Also, I made sure it is checked in the "Allow extension path to execute

4. In IIS, I moved the Shibboleth to the top of the list in "ISAPI"

5. I made sure the daemon service is running in the "Services"

6. In command prompt, I ran "shibd -check" and the service is running
without issue

7. In the server, I went to "http://localhost/Shibboleth.sso/Status" in IE
browser but it return the below message:



** Error Message **

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its
dependencies) could have been removed, had its name changed, or is
temporarily unavailable. Please review the following URL and make sure that
it is spelled correctly.

Requested URL: /Shibboleth.sso/Status



8. It seemed like the Microsoft files over power (or overridden) the .sso
and was not able to resolve the Shibboleth request. Therefore, I removed
the .sso from "Handler Mappings" and the Shibboleth in "ISAPI", then
installed them again, manually. However, the error message still occurs.



** Log Files **

Window Log File:

2012-05-15 11:57:13 ::1 GET /Shibboleth.sso/Status - 80 - ::1
Mozilla/5.0+(compatible;+MSIE+9.0;+Windows+NT+6.1;+WOW64;+Trident/5.0) 404 0
0 546



Shibboleth shibd.log:

2012-05-15 11:42:14 INFO Shibboleth.Listener : listener service starting



Shibboleth native.log:

2012-05-15 11:31:20 INFO Shibboleth.SessionCache : cleanup thread
started...run every 900 secs; timeout after 900 secs



Shibboleth native-warn.log:

2012-05-15 11:57:52 ERROR Shibboleth.Listener [2896] isapi_shib: remoted
message returned an error: No destination registered for incoming message
addressed to (rename--my-application-name::getHeaders::Application).

2012-05-15 11:57:52 ERROR Shibboleth.ISAPI [2896] isapi_shib: No destination
registered for incoming message addressed to
(rename--my-application-name::getHeaders::Application).



**********



For testing, I have IIS pointed to another web folder with Classic ASP codes
and Shibboleth was able to ask user for username/password, then returned to
the website.



However, Shibboleth stops working when the IIS points to the web application
written in MVC codes.



Any advise would be greatly appreciated.





Regards, Raymond

[Cantor, Scott]

Post by Raymond Lam
8. It seemed like the Microsoft files over power (or overridden) the .sso
and was not able to resolve the Shibboleth request. Therefore, I removed
the .sso from ³Handler Mappings²
and the Shibboleth in ³ISAPI², then installed them again, manually.
However, the error message still occurs.

Your diagnosis sounds correct. Your .NET app pool or whatever it's called
is overriding various settings and that's the problem. It's a trial and
error mess of trying to convince IIS to accept the settings. I don't use
IIS or .NET in any real world capacity, so all I know is the fact that the
mapping isn't active, which you already identified as the problem.

I don't believe running the app pool as 32-bit would cause a 404, but you
might verify that also, since you installed the 64-bit version.

-- Scott

--
To unsubscribe from this list send an email to users-***@shibboleth.net

[Ina Müller]

Post by Raymond Lam
However, Shibboleth stops working when the IIS points to the web
application written in MVC codes.

we have Shib protected asp.net applications in both WebForms and MVC3
style. We didn't see any difference with Shib ISAPI filter.

Do you host the MVC app at WebSite root? Then I could imagine, that the
MVC routing module would intercept with the Shibboleth.sso handler, so
you should test your MVC app under sub url (localhost/mymvcapp). If the
Shibboleth.sso/Status still not working, your problem is not MVC routing.



--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Cantor, Scott]

Post by Ina Müller
Do you host the MVC app at WebSite root? Then I could imagine, that the
MVC routing module would intercept with the Shibboleth.sso handler, so
you should test your MVC app under sub url (localhost/mymvcapp). If the
Shibboleth.sso/Status still not working, your problem is not MVC routing.

That reminds me, somebody at one point did have a case where a wildcard
script mapping was superceding the one for *.sso

I wasn't able to reproduce that, but that would match the symptom.

-- Scott

--
To unsubscribe from this list send an email to users-***@shibboleth.net

[Luke Tillman]

I just ran into a similar problem when setting up an MVC site with the SP.
You might try making sure that you have runAllManagedModulesForAllRequests
set to false in the Web.config for your MVC site:

<modules runAllManagedModulesForAllRequests="false" />

I think some managed module must have been intercepting the request for
/Shibboleth.sso/Status and giving me a 404. Once I turned that off, I was
able to access the handler. Make sure you understand the implications of
changing that setting though (it has other effects).



--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Shibboleth-SP-with-Windows-IIS7-and-MVC-tp7560582p7573867.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Raymond Lam]

Hi Luke,



After I set the runAllManagedModulesForAllRequests to false in web.config,
the MVC code is able to run.



I will watch out for the implications of the change and thanks for the
suggestion.





Regards, Raymond





-----Original Message-----
From: users-bounces-***@public.gmane.org [mailto:users-bounces-***@public.gmane.org] On
Behalf Of Luke Tillman
Sent: Wednesday, May 23, 2012 10:28 AM
To: users-***@public.gmane.org
Subject: Re: Shibboleth SP with Windows IIS7 and MVC



I just ran into a similar problem when setting up an MVC site with the SP.

You might try making sure that you have runAllManagedModulesForAllRequests

set to false in the Web.config for your MVC site:



<modules runAllManagedModulesForAllRequests="false" />



I think some managed module must have been intercepting the request for

/Shibboleth.sso/Status and giving me a 404. Once I turned that off, I was

able to access the handler. Make sure you understand the implications of

changing that setting though (it has other effects).







--

View this message in context:
http://shibboleth.1660669.n2.nabble.com/Shibboleth-SP-with-Windows-IIS7-and-
MVC-tp7560582p7573867.html

Sent from the Shibboleth - Users mailing list archive at Nabble.com.

--

To unsubscribe from this list send an email to
users-unsubscribe-***@public.gmane.org



-----

No virus found in this message.

Checked by AVG - www.avg.com

Version: 10.0.1424 / Virus Database: 2425/5017 - Release Date: 05/23/12

[Cantor, Scott]

Post by Raymond Lam
Hi Luke,
After I set the runAllManagedModulesForAllRequests to false in
web.config, the MVC code is able to run.

Is this specific to ane on IIS version, or just all of them? I want to
document the issue on the installation pages (or, it would be nice if one
of you could).

-- Scott

--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org

[Andrew Webb]

In IIS, I moved the .sso file extension to the top of the list in "Handler
Mappings"

A solution that works for me, and which I find less messy than manipulating
the order of the handler mappings at site level (which modifies your
Web.config) is to tell MVC to ignore .sso routes in code. The syntax for
ignoring routes is complicated and not very well documented, but Microsoft
provide an example for the .axd extension in every newly-created MVC
project. So I copied what MS do, and have added this to my MVC web app (in
Global.asax.cs):-

routes.IgnoreRoute("{resource}.sso/{*pathInfo}");

With this in place, Shibboleth.sso runs correctly wherever the .sso handler
mapping is in the ordered list. Also I don't have to set
runAllManagedModulesForAllRequests (RAMMFAR) to "false" (although it's a
good idea to do so, if you can - and I can).


--
View this message in context: http://shibboleth.1660669.n2.nabble.com/Shibboleth-SP-with-Windows-IIS7-and-MVC-tp7560582p7580709.html
Sent from the Shibboleth - Users mailing list archive at Nabble.com.
--
To unsubscribe from this list send an email to users-unsubscribe-***@public.gmane.org