Shibboleth Developers

[Scott Cantor <>]

At the end of the last call, I offered to write up something about what I
"thought I heard" to be the basic approach and requirements for the Java
target implementation. Hopefully just a sanity check. As part of this, I'm
struggling to define a vocabulary for talking about the target, so forgive
the rambling.

Ignoring the language and J2EE for the moment, I want to outline the basic
components from a SAML perspective. This is not a perfect description of the
current C++ target, but it's where I think I'm headed, and it's not all that
far off anyway.

General Architecture

Conceptually, I'm trying to move to a target design in which a set of
applications/services can coexist on a single host or across multiple hosts.
A SSO "session" is between the origin site and one of the applications. That
is, each application has an independent session with the browser. I'm not
talking about a particular physical session (such as a J2EE JSESSION cookie,
or the current Shib cookie), just the logical notion.

The target is divided into two functional components, a SAML assertion
consumer service (the so-called SHIRE) that creates logical sessions on
behalf of an application, and the session interface that can obtain/cache
attributes for a session and make them available to either the application
or a resource manager. We know from experience that the actual design may
not be that clean, but for this purpose it serves.

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.

Once that's done, on any subsequent request, the physical session can be
used to recover the logical session "object" and convert it into an
attribute set. As we discussed, that conversion can be a delayed query, or
done at session creation/checking time (Derek can explain at length why we
do it up front, but basically we don't know if the handle is valid so we
check the session's validity on each request by insuring we have a valid
attribute set before the request runs).

From the above, it follows that the persistent state of the system is the
data associated with the logical session, the SSO assertion and any
associated attribute assertions. The current SHAR design encapsulates the
caching of this data by storing it after session creation and any subsequent
calls to verify the session or get the attributes. Thus, the three-function
remoted SHAR interface of create_new_session, is_session_valid, and
get_attributes. This could as easily be expressed as methods on a session
object, with no real difference.

Java Architecture

Now, moving into the concrete, we ideally want the shared session state to
be potentially available from anywhere that the same physical session can be
accessed. Walter notes some Java containers support "session migration", and
that with the proper runtime support, a logical session "object" could be
pinned to a session in one JVM and migrated to another.

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.

With the object in the session, it seems like the actual use of the object
could be wrapped in a Java filter (which was discussed on the call) or
exposed via an API (perhaps simply the object's interface itself) to an
application directly.

In the latter case, we don't necessarily need as much functionality to map
URLs in the container to the act of session creation, since an application
could simply trigger this on demand. That would lead to a redirect to the
WAYF, back to the SHIRE, and eventually back to the application with the
session established.

A filter would certainly work also. It would, as Apache does, determine
whether to "validate" the session object based on the request (its URL or
some other servlet context property), at which point the same functionality
kicks in. As we have yet to build with the C++ target, we know we need a way
to map from requests to the application identifier for SAML purposes, and
should come up with a shared config approach for that.

The resource manager piece can fit in here as needed, either as part of the
filter, or just a plugin API callable by an application (conceptually taking
the session as input to the policy engine, and spitting out the answer).

Underneath the covers, most of the real target details, configuration,
metadata, etc. is all internal to the session object, I think. Even the
SHIRE can really farm out the work to a session factory/constructor, handing
it the SAML data as input. This is more or less how things work now.

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.

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.

So in closing, I think we have a lot of stuff we can adapt readily, and it's
just a matter of exposing that code for internal use and then providing the
two functional components (SHIRE and session interface).

Thoughts?

-- Scott