Shibboleth Developers

["Scott Cantor" <>]

> Another problem I'm having now is regarding the load balancing of the
> SPs. Our applications normally have more than one front-end behind a
> VIP and a cluster os Perlbals.

Ok. And before Shibboleth came along, how did you handle sessions? Whatever
that answer is, why don't you just keep using it and leave Shibboleth
handling only the front end?

> What this means is that sticky
> sessions would not be very efficient.

For 5 minutes? I can't imagine a short factor to get the user through POST
and one redirect would be a big deal.

> Most of the applications use a database to
> store their sessions so a session cache plugin that used this
> database would be a good option I think.

I think you're going to find that it will be much more efficient to leave
the Shibboleth session out of the equation.

> I read in the wiki that
> Shib2.0 would include a cache plugin that supports ODBC, this will
> solve my problem right?

Well, there will definitely be a plugin. It will work as well as ODBC can
work on Unix (it will probably require tweaking for different platforms
because drivers will be hit or miss). It will also require that every
request into the server hit the database to update the "last time accessed"
information in order for timeouts to be enforced.

I think that's a questionable approach if you already have a database-backed
session mechanism, but the choice is really up to you. I also don't like the
fact that you end up with a single point of failure in the database.
 
In truth the plugin is less for the session cache and more for the purpose
of tracking replay and handling things like sending messages to an IdP via
artifact without requiring shared memory. That's much more lightly used than
a full session cache would be.

But the persistence layer is all one interface now, regardless of what's
stored, so one plugin can be used to manage storage for all the different
components that potentially store data. The default session cache in the SP
is "StorageService-backed", meaning you configure it to use a particular
storage plugin. That can be in-memory, in which case it works somewhat like
now, or it can be a database plugin. The cache itself is not written for a
specific back-end now, which means the storage plugins are much simpler.

If you're interested in helping with the ODBC cache, I'd be happy to point
you at it. It's basically waiting for a final rewrite against the storage
API. Jim did a first cut, and it just needs some tweaks.

-- Scott