Shibboleth Developers

["Scott Cantor" <>]

> What cannot happen is it it cannot go to /Shibboleth.sso, a URL in the 
> ROOT of the server. In the ISAPI Apache world there was no 
> need for a specific context to be mentioned, so it was common 
> for the handlerURL to reference the dummy Shibboleth.sso and 
> before it Shibboleth.shire in the "root" directory of the 
> server, but that was sloppy syntax and now it comes back to 
> pose a problem.

I understood this particular problem, but I was asking whether there were
other distinctions, and there probably are, perhaps for valid reasons.

In this case, I would disagree that it's "sloppy" syntax. It's somewhat
annoying to configure a handler deeper in the tree on IIS. That would be an
additional configuration step for users. A better option might be to
actually deliver a separate DLL to act as the handler and force the user to
actually physically deploy it in the tree where required. As long as the
whole thing is going to be "faked", doing it at the root is just less work.

Apache isn't quite so troublesome, and you can pretty much run the handler
from anywhere, it's just the extension that matters (and in 2.0 not even
that, the handler grabs every request and skips the ones that don't match).

My default also emphasizes that it's probably a bad idea to try and subset a
vhost by creating separate applications within a vhost and thus defining
handlers like /app1/Shibboleth.sso and /app2/Shibboleth.sso. That is
somewhat misleading, basically, even though the software supports it. (And
yes, my commented out example of a second Application is showing exactly
this, I'm going to get rid of that.)

The implication of that is that the Java model of separate apps within a
vhost is questionable, and I would argue that it is, but that doesn't really
help since it's the servlet spec that's causing this, not the Java SP. I
don't think there's any way to catch a request to /Shibboleth.sso, though if
there is, I'd do it that way personally.

I guess that leaves us with a difference. I could change the default on at
least Apache, if there was some convention to use (/shibboleth-sp I guess).
It's probably possible to rig the IIS installer to do this on Windows and
maybe take the hassle out, but obviously that would be a next release thing.

> While I believe that the syntax of the configuration file 
> should be roughly the same in all implementations, I do not 
> think that this extends to the contents of XML attributes 
> whose type is designated to be URIs. There will be 
> differences in URI format based on local conventions and 
> server choices.

It's probably more a question of whether the defaults match or not. Where
the handlers are concerned, it's certainly uncommon to change the defaults
unless there's a good reason. Maybe that's not true for the Java version
though.

I guess for Nate's stuff, the problem is we'd have to know which SP was
being used and generate different defaults. I agree that's not ideal.

I think we should determine the scope of the potential differences and then
see whether changes are practical.

-- Scott