Shibboleth Developers

["Scott Cantor" <>]

> While I am sure this is an interesting example, it has a 
> massive architectural impact on complexity and efficiency. If 
> I could assume that every Web Application context had a 
> single Shib Application element (which makes a lot of sense 
> in Java terms) then the Filter can obtain and cache a lot of 
> parameterization from the Shib Application. This example, 
> however, forces the RM Filter to regard Application 
> affiliation as a feature of the individual request and forces 
> it to refetch the data for each operation.

Obviously, the original SP has to do this no matter what, since there's
little or nothing I can rely on across servers.

1.3 does support "Native" mappers which enable Apache or obj.conf commands
(and later IIS metabase properties) to supply the settings in the RequestMap
directly to the mainline code without using the XML lookup process.

With Java, the equivalent mechanism would seem to be context properties (or
something along those lines, I assume) and those are of course vastly less
powerful since they're per war, not per resource.

It seems reasonable to allow that. Seems to me that you could have the Java
version of the "Native" mapper refuse to delegate to the RequestMap, thus
properties would only be per-context, or if you enabled the XML mapper
plugin, you'd get richer support but higher runtime cost.

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

-- Scott