Shibboleth Developers

["Scott Cantor" <>]

> 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.

> Regarding 2.0 (trunk of repositories) I see a shibsp/SessionCache.h
> (which is the Storage API?) and it is implemented by shibsp/impl/
> StorageServiceSessionCache.cpp (memory based cache?) and odbc_ccache/
> odbc-ccache.cpp (odbc based cache?).
> 
> Am I right? Also, what is the RemotedSessionCache?

You do not need to do anything with the SessionCache APIs in 2.0. There are
already two plugins that should be sufficient for now. The Remoted cache is
just a stub that lives inside mod_shib and buffers sessions in memory that
are managed in shibd. The "real" cache is the StorageService-backed plugin.

> In a previous thread the cpp-xmltooling repo was mentioned and I
> found a caching API there but I don't know the relation between this
> cache and the SP session cache. (xmltooling/util/StorageService.h)

The only thing you have to implement for 2.0 is a StorageService plugin. It
knows nothing about the data being stored, it just has to follow the rules
and provide a bunch of different features like versioned reads and writes,
and the ability to update the record expiration time.

The ODBC version will be done soon, until then only the in-memory version
inside the xmltooling library exists as a sample.

If you write a SS plugin, your new backing store can be used for the session
cache, replay cache, and the artifact mapping store without any special
work. All the code is written to that API.

The SS API stores data in "contexts" to allow one database table to be used
to store a lot of different data. In SQL, it's just a separate column making
a two part key. You don't have to care about how the other pieces of code
actually make use of the two parts but if there are efficiency issues, I can
outline some of that.

-- Scott