Skip to Content.
Sympa Menu

shibboleth-dev - Re: Location of SP Session Cache

Subject: Shibboleth Developers

List archive

Re: Location of SP Session Cache


Chronological Thread 
  • From: André Cruz <>
  • To:
  • Subject: Re: Location of SP Session Cache
  • Date: Sun, 10 Jun 2007 20:19:04 +0100

Sorry to bring this subject back again but only now I got the opportunity to look at the 1.3 code.

On 2007/05/29, at 19:43, Scott Cantor wrote:


Regarding 1.3 there is the ISessionCache present in shib-target.h
which is implemented by shib-ccache.cpp (memory based cache) and shib-
mysql-ccache.cpp (mysql based cache).

The 1.3 cache is a huge mess. It was supposed to get better, but I botched
it and made things even worse if that's possible. You have to implement the
IsessionCacheEntry interface to actually supply the different storage
routines, but also wrap the in-memory ISessionCache implementation. It's
probably a small bit easier than with 1.2, but it's just as confusing.

You pretty much have to copy the MySQL cache plugin.


I don't understand why we have to wrap the in-memory cache. Surely this can cause the in-memory cache to become stale in some situations?
Taking as an example the mysql cache: if in machine A a session is accessed, the mysql cache and in-memory cache of machine A update the last access time of the session. If the same session is accessed via a shibd process in machine B, the session is fetched from the in- memory cache before the mysql cache (assuming it was already there) and so the last access time is wrong. Or maybe this is not a problem?

Anyway... In 1.3 the only caches that need to be distributed are the session cache and replay cache found in shib-mysql-cache.cpp, right?

The reasons this distributed remote cache looks interesting to me are:
- lower memory consumption on the machines running shibd. Normally these machines are the front-ends of our applications which have better uses for their RAM.
- no need for sticky sessions.
- if I can organize the session cache by userid maybe I can remotely kill all the SP sessions of a specific user by deleting his entries from the memcache cache (that's another reason for not wanting to wrap an in-memory cache) and therefore have Single-logout on 1.3. :)

Is this too much fantasy?

Thanks for your help,
André


Archive powered by MHonArc 2.6.16.

Top of Page