Shibboleth Developers

["Howard Gilbert" <>]

> > If you want to have another Application (Shib), you should
> > site it in another Web Application (WAR), not in a
> > subdirectory of some existing WAR. Or at least that is a
> > restriction that I would propose to add to the Java SP unless
> > someone would like to defend this RequestMap example as a
> > valuable real world feature.
> 
> I don't see why it has to be either/or. I architected my version to leave
> this sort of thing up to the deployer, essentially, it doesn't really
> affect
> my code since access to the information is hidden behind a RequestMap API.

There are so many possible requirements that I have always tried to
advertise the RM (Filter) as example code that a programmer can customize to
the requirements of the application. However, I am casting around for a
"philosophy" or "best practice" to document and I don't think that
constantly deferring decisions to the SP is anything that one would have
designed for Java if the syntax had not already been around for the other
languages and web servers.

If I start without presupposition and as how I think a general purpose
plug-in RM would be designed when there is a Web Application (WAR) with
different resources having substantial differences in their authentication
requirements, I suspect the answer would be to deploy more than one Filter
mapped to different URLs, or at least more than one instance of the Shib
Filter with different URL mappings and different initialization parameters.

This provides a conceptual model that makes sense. Each instance of the
Filter can now settle down to do whatever authentication function is implied
by its corresponding <Application>, supplemented by its local initialization
parameters. In particular, it can cache more information because it is not
schizophrenically switching personality with each new request.

This now provides a programming and configuration model that modularizes
concerns and provides a roadmap for adapting the configuration syntax to the
particular concerns of new webapps.

So consider the title of this message amended from "Multi-Application
Contexts" to "Single <Application> Filters", allowing for more than one
Filter per Context when it makes sense.