Shibboleth Developers

["Howard Gilbert" <>]

> The result of this is that implementing Shib as an HttpModule would leave
> people exposed when they inevitably assume that .NET security would
> protect
> all their content, and not just the ASP. I've seen that noted on web
> sites,
> in fact. It might also *only* work for ASP.NET-based sites, and that's not
> always what people pick IIS for. Not here at OSU anyway.

This, I think, is a misunderstanding of the complete reversal in thinking
that goes into IIS 6. Apache is a Web Server (vending pages) that runs
applications (CGI, Servlets) on occasion when the URL matches a configured
pattern. IIS 6 and ASP.NET are installed to Windows 2003 as an "Application
Server" that runs applications and, in the degenerate case where an
application is not configured to a particular file extension) falls through
to the default application that returns the named file.

You can change that default application, at the cost of building your own
code that runs the few lines of code that implement the "return this named
file as the response" logic. Therefore you can protect the data by the
mechanism of protecting only the applications, when you realize that in IIS,
returning the data file *is* an application.

I have avoided volunteering anything, but in the spirit of cooperation I
suppose that I might mention that the / context in Tomcat is an application
called ROOT and it can be configured with its own WEB-INF and its own
filters. As I noted, the handlerURL can be either
/shibboleth-sp/Shibboleth.sso or /secure/Shibboleth.sso, and I suppose it
could also be /Shibboleth.sso if I added the ROOT context and put the
Shib-Filter in its web.xml. If there was something else in ROOT, I could
mark all the ROOT content to be not-shib-protected so the only time the
Filter would do anything is if it got the Shibboleth POST, and then it would
create the session and redirect the request on to the Target. 

If this is deemed to be desirable, I will have to go back over my RequestMap
thinking. I had to jump through some hoops to make sure that the POST is
processed and the Session created against the correct Application Id (the
one that is RequestMapped to the Resource URL and not to the handlerURL). If
you now add a third context to the map I need to go back over the code to
make sure there was no two-context assumption in that logic.