Shibboleth Developers

["Scott Cantor" <>]

> Well, the problem is that IIS 6.0 completely changed the programming model
> without changing the configuration semantics. The result is probably a
mess.

I think it's always been a mess, but I don't see anything fundamentally
changed about ISAPI filters, apart from the process pooling. As a developer,
I don't have to care that the filter happens to be running inside each
process on demand, as long as I didn't make bad assumptions that were never
part of the documented API. Microsoft never promised me a single process.

> Microsoft might have at least apologized for this, except that they are
now
> concentrating on the ASP.NET environment where you would probably
configure
> your Filter as an HttpModule in the .NET stack where everything is
> application specific, just like it is in the Java Servlet environment.

The problem with this is static content. With .NET, you have to *explicitly*
tell the ASP.NET DLL to process static files. With Java, you don't, since it
*is* the web server.

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.

> So if putting Shibboleth.sso at the root isn't sloppy syntax because it
> reflects the reality of Apache and IIS 5, then it is at least non-portable
> syntax because it does not reflect the reality of J2EE and IIS 6 or
ASP.NET.

It actually does reflect my feelings on IIS6. I have no doubt somebody
(maybe even me) will do an HttpModule version, but I'm not convinced it's
the right thing yet. Note that the ADFSweb agent (designed for IIS6) is an
ISAPI filter.

It may definitely be non-portable to Java though. Assuming there really is
no way to hook something at the root, anyway.

> If the latter, then we must agree that the configuration file is different
> because the URL semantics accurately reflect the underlying differences of
> the various Container models.

As I said, I think I can change it to /shibboleth-sp/Shibboleth.sso if it
turns out that this is the deal-breaker. I'm not sure yet that this is the
only difference. Perhaps it's the biggest one though.

OTOH, changing it just for this does get annoying because people have
deployed the thing, and it already sucks that we end up changing metadata to
reflect an upgrade to 1.3.

One reason I wouldn't be that opposed to changing it if it turns out to work
alright is that there's another use for creating a /shibboleth-sp virtual
directory in an IIS site, which is to supply content like logos and style
sheets for the error pages. And /shibboleth-sp is actually the default path
we use there.

The main problem is getting the installer to do it, unless we can buy more
of Atticus' time to help me. As it is, there's an IIS6 change to make anyway
because putting the .sso script mapping at the Web Sites level isn't working
any longer due to the Default Web Site overriding the full set of mappings.

So, leaving aside the design issues on which we might disagree, is this the
only major divergence apart from functionality that just might not be in the
Java version yet?

-- Scott