Shibboleth Developers

["Howard Gilbert" <>]

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

In the IIS 5 days, the IIS server component ran as a process/address space
that received traffic at various configured TCP ports. Any filter ran in the
same address space with the Web Server. Some applications would be
implemented in the Server address space (like ASP scripts), while others
would run in separate isolated address spaces to which the Server
communicates with COM+.

In IIS 6, however, the Server moves to the Kernel. Now HTTP headers are part
of the Kernel decoding just like port numbers. A URL is resolved to a
particular virtual application by looking at the context name (just like the
Servlet model). However, since ISAPI filters are installed at the Server
level, and Microsoft refused to change the configuration semantics, a
separate instance of the ISAPI Filter DLL is loaded into every address space
of every "application" configured for that site. It works almost the same,
unless you were counting on static data in the DLL being available across
applications.

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.

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.
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.

> -----Original Message-----
> 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.

> 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.)