Shibboleth Developers

["Scott Cantor" <>]

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

Yuck. Is that indicated by these lines in the web.config file that is
referenced inside the Master Web properties?

<add path="*" verb="GET,HEAD,POST" type="System.Web.DefaultHttpHandler"
validate="True" />
 <add path="*" verb="*" type="System.Web.HttpMethodNotAllowedHandler"
validate="True" />

But what happens if ASP.NET is disabled? There must be some kind of fallback
to more typical behavior.

My point about people leaving content unprotected isn't speculation, BTW, I
found several mentions of it. The problem is that doing it at the .NET level
means changing the configuration of every .NET application installed, not
just the one at the "root". I think that's bad, if true.

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

That is more or less how I would have approached the design myself because I
think the processing should be application-independent, but there might be
implications or problems porting that to other containers that I wouldn't
have been aware of.

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

I think that works regardless, actually. I forced them to be one and the
same by mapping the handlerURL itself, but I hadn't considered using the
resource URL at the time, and that might be a better approach. We probably
argued about this, but I clearly didn't grok the issue at the time, or was
lost in some other problem. I'm not saying "let's do it my way", I'm just
trying to understand the options.

In the Java case, I never even argued explicitly that the Application notion
made sense, since there's already a very explicit notion of separate
applications in the container through contexts. It might be perfectly
reasonable to force all content within a context to map to a single set of
SAML configuration options, error handling, etc. I didn't have that option
in the more general case. It was either apply everything at the per-request
level, or aggregate it in some arbitrary, user-specified way.

So I'm left wondering if it wouldn't make sense to just have both SPs using
a single set of handler endpoints and determining settings based on the
resource URL, which might simplify things vs. my approach when dealing with
multiple applications. Either way, each vhost in my world potentially has to
support those endpoints, but that's separate from where the handler lives,
at the root or some other fixed location.

In Java, you have to configure the filter in each context anyway, right? So
there's less to be gained from doing it at the root. I would argue that
there's a good reason to it if the filters on the root context automatically
run on all the others, that's much less set up.

Otherwise, maybe we should decide whether my code should change instead, and
then /shibboleth-sp as a default would be ok. Wouldn't happen until 2.0 of
course.

-- Scott