Shibboleth Developers

["Howard Gilbert" <>]

> > The user requests http://server/resource/thing.
> > The Resource Management Filter decides to protect this resource.
> > Typically the Filter redirects the request to the Servlet.
> 
> Couldn't it just generate the redirect itself? I use a redirect to the
> SHIRE
> "handler" as a way of generating a redirect only to support lazy sessions,
> but since it's an extra redirect, it's best avoided if you can, I would
> think.
> 
> The language you use later makes me think I just don't fully grok the
> architecture of how things are set up re: the filter vs. the servlet and
> such. I will read your note on the web page however before asking dumb
> questions.

The problem is that a Filter may or may not, depending on configuration,
share resources across different context (directories) in the same Web
Server. So if you have multiple Applications in multiple contexts in the
same Web Server sharing a common /shibboleth context in which the
Shibboleth/SHIRE/SHAR objects reside, then it gets a bit more complicated
for the Filter to make this decision itself. It is simpler to shunt the
request over to /shibboleth/Shibboleth.shire and let the Servlet decide what
to do.

The RequestMapper could map two different Filters in different context
environments to the same applicationId, and therefore the same Session. The
first time a user visits either Resource he gets a POST and a Session and
maybe attributes. If he now visits the second context, the Filter running in
the isolation of that context would to jump through some hoops (and I would
have to build those hoops) to find out if a session already exists. The safe
and simple trick is to always redirect through the Servlet. If a session is
needed, the Servlet sends it on to the WAYF. If it isn't needed, it
redirects back with the same [as yet not firmly determined] magic that
signals to the Filter that a Session has been established and it should
claim its pending attributes.

Technical background: A Servlet container like Tomcat runs under a single
JVM. However, objects and classes are partitioned depending on the
Classloader they come from. There is one global classloader for stuff in the
{tomcat}/common/lib and a different classloader for each context that loads
the {context}/WEB-INF/lib and {context}/WEB-INF/classes. Thus even if
different contexts load the same filter class using the same fully qualified
path name, they will get different class objects and different static fields
if the shibboleth stuff is in the WEB-INF of each context. There are J2EE
solutions to create shared objects, and some version of this is the most
direct way to transfer the attributes. That't the part I have to work out
next.