Shibboleth Developers

["Howard Gilbert" <>]

Last week I promised an update by mail whether we have a call today or not.

In the last week, the Resource part of the Java Target was cleaned up. A
separate project was created to build just the
edu.internet2.middleware.shibboleth.resource package which now contains just
the AuthenticationFilter class. This roughly corresponds to the ISAPI and
Apache filters in existing target code. It is a separate project to create a
separate JAR file so the Filter class can be run all by itself from other
"contexts" (subdirectories). The rest of the Target (and the Origin for that
matter) resides in the /shibboleth context and the JAR file that contains
all those classes exists locally within that context. The Filter class
resides by itself in its own JAR file and can be added to the web.xml
configuration file of any other context to get Shibboleth protection. [Java
filters must be configured directory by directory and cannot be added to
filter the entire Server].

This produces an overlap between the configuration of the Filter in each
context (which didn't exist in C++) and the RequestMapper Path element
requireSession attribute. The current code punts. There is some hardcoded
support that allows testing, with details to be filled in. Currently,
RequestMap is used to determine the applicationId, and additional functions
will be added shortly.

Currently attributes are fetched immediately after the Authentication POST
has been processed. This simplifies testing and debugging because you know
where and when the attributes will be fetched through SAML. 

Communication between the Filter and the other Shibboleth Target classes
(the operation that corresponds to ONC-RPC in the C++ code) may have to be
done several different ways. If we could assume a complete J2EE environment,
then it could be handled by an EJB. However, Shibboleth will typically run
on a Servlet-only subset of J2EE, where the exact details of separation
between contexts is up to the server. The current code does the simplest
thing that works in Tomcat (and probably most simple Servlet containers).
The Filter JAR file is simply placed in the shared library
({tomcat}/common/lib/shibfilter.jar) where the system loads one copy of the
Filter class to be shared among all contexts. The connection back to the
/shibboleth classes is made through a static field. This needs to be
tightened up and will be, but the current code is good enough for now.

When the Filter is defined in the web.xml of each context, it can be given
parameters that define the WAYF and SHIRE URL and the providerId. Normally
it will get these values through its interface to the /shibboleth classes
(who have access to the parsed configuration file), but that support hasn't
been added yet.

The attributes are fetched, put through all the Trust and AAP processing,
and stored in the Session object. In the next couple of days I will finish
the handoff of the attributes to the Filter and the interface between the
filter and the Applications (creating a Servlet-session object, creating
dummy headers, honoring exportAssertion from the RequestMap. The current
code has the attributes in the /shibboleth context, as you can verify with
debugging or logging. However, the handoff is more complicated because it
has to draw not only on the attributes, but also on the RequestMap and AAP
plugin providers (to get parameters), and to simulate additional Headers and
a few other things, the Filter has to create a Wrapper class that overrides
a bunch of Request object methods. This is routine but tedious code.

I have not aggressively tested all components, so while the code has all the
logic and performs all its major functions, I do not assert that every
attribute of every configuration element is being properly applied.

An updated zip file of the workspace will be posted later today. To use the
code, you should have Java 1.4, Eclipse 3.0 to run the Workspace, and Tomcat
5.0.27 to run the code. Detailed setup instructions will follow.