Shibboleth Developers

["Howard Gilbert" <>]

"The physical manifestation of a session in SAML is the SSO assertion that
contains the principal's NameIdentifier, so the job of the SHIRE is to
process/validate that assertion, create the logical session, and bind it to
the NameIdentifier and a physical session with the user. Then it redirects
the browser to the application URL."

More specifically, the SAML assertion consumed by the SHIRE is in the form
of an HTTP POST to a specific URL. I tend to regard everything before the
POST (any previous URLs, WAYF stops, redirections, and institution specific
Web Signon procedures) as implementation details. Shibboleth specifically
leaves these issues vague and up to the code in question. The first concrete
protocol element is the format of the POST. Even here, however, there is
uncertainty about the URL to which the POST is directed, and the question of
redirection after the POST.

This is somewhat important in the Java design because there are two ways to
approach the SHIRE. Some background is needed to form the question.

Each application that runs in a Servlet host container is associated with a
"context" identified with a virtual subdirectory. For example, there might
be an application that handles homework in the "/homework" context and one
that distributes music in the "/music" context. All contexts share the same
Java Virtual Machine, but each context is distributed with its own class
libraries and is configured with its own XML configuration files. When two
applications in two different contexts create objects of the (say)
edu.internet2.shibboleth.Shire class, you can configure this to either use
two different though possibly identical copies of the Shire class loaded
from different class libraries, or to create different objects from the same
class. When the same Class is used, static objects are shared between the
two applications.

Sometimes it is not good enough to maybe share classes. Sometimes you even
want to share objects. In the modern J2EE world, this can be accomplished if
a particular class creates a object during Server initialization and then
registers a reference (pointer) to the object in the internal in-memory LDAP
directory. When the contexts start up, they can make a directory call for
the name under which the object is stored and obtain a global pointer to the
registered global object.

An alternate, though less efficient, way to obtain shared access to an
object is to create a context (which I will call "/shibboleth" since that
would be the obvious name to use for the application if you decided to do
things this way). It could contain both the SHIRE and SHAR functions,
accepting the POST data with the handle when it is acting as SHIRE and
redirecting the Browser on to the real application context with some
appended handle/session designator, then accepting a Web Service request
from the real application to obtain attributes. This has the advantage that
the SHIRE/SHAR could be in a different server and JVM from the one in which
the application resides.

If you go with the first model, where the SHIRE/SHARE represent some classes
that form basically a "layer" in the request processing, then Shibboleth
processing can be done through a Servlet Filter that front-ends the
application and there is no need for a final redirection.

The user makes a request to the application URL.
The Shibboleth filter processes the request and redirects it as needed to
the WAYF, HS, ..., until the HS eventually POSTs the architected assertion
containing the SAML handle assertion. This POST can go back to the same
application URL where it again is processed by the filter.
The session state, handle, and any attributes fetched are stored either in
static class space or in the global LDAP object. Either way they are shared
among all contexts on the machine that use the same class or LDAP object.
The filter logically removes the Shibboleth stuff and allows the request to
fall through (not redirect) to the application.
If you absolutely needs to share session status across different JVMs, one
JVM could be authoritative for any given session and other JVMs could
remotely access it. This is a hybrid that uses the highly efficient filter
layer model for contexts on the one machine, and the less efficient but more
general Web Service model for all other contexts.

The alternate design is to create a single Web Service model used both
locally and remotely.





"Returning to the beginning of the flow, we presumably see the SHIRE being
implemented as a servlet, since it's an HTTP request processor. The session
object that it creates and pins into the physical session would represent
the interface between the rest of the target functionality and the
application in the JVM."

If we can reasonably assume that there will be a filter in front of every
Shibbolized Java application, no matter how the SHIRE/SHAR are implemented,
then we can make use of the Servlet conventions. When a filter wants to add
function that the application can use, it "wraps" the original HTTP Request
object in an object it creates that implements the same interface, passes on
most of the calls, but adds additional function to one of the calls thus
appearing to extend the information in the "Request" object. So from the
application program's point of view, we can trap calls for a particular
header or property and return something the application can use to get
attributes.

Everything else is an implementation detail under the covers. It may be that
the attributes are cached or they might be fetched on request. The
processing could use static data in classes, or it might be a remote request
to a Web service. Given enough enthusiasm, different people could write
different implementations and the applications would not know which
implementation they were talking to. A simple version for the single Tomcat
server could handle small applications, while a Web Service based scalable
version could handle load balanced configurations.

If this is acceptable, then there are two public standards:

1) What does the getUserAttribute() method look like and how is it chained
to the extended Request object? Do we need any other methods to force
session termination or other lifecycle things?

2) What does the Web Service look like and what gets passed when the SHIRE
redirects the request to the application so that the application can find
the Web Service and present the Session identifier to obtain attributes?

These are the local and remote versions of the same operation. Now strictly
speaking, a version 2) operation will be hidden behind the filter as the
implementation of a version 1) call, so the application doesn't care what
the Web Service looks like, but I think we should standardize it as a
potential public API for situations (like .NET) where the Java Filter isn't
sufficient.




"We agreed on the call that it's best to try and reuse as much of that
existing design and code as we can. All of the metadata APIs and
configuration should transfer pretty readily, with Java interfaces exposing
a similar API as the C++ abstract base classes I built do. The C++ modules
don't really call most of that directly anyway, it's done internally behind
a lot of helper classes and functions that we can port or adapt."

That's the question. What functions need to be exposed in the new API.
Assume that the session has been created magically. What do you need to
expose from it afterwards.


"We'll want to explore the general issue of target configuration, which is
currently driven from an ini file, but XML is probably easier to deal with
in Java."

Filters get initialization parameters from the context configuration. Global
stuff gets initialization parameters from the global server configuration.
This is just a case of deciding what to carry over.