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: "Scott Cantor" <>
  • To: <>
  • Subject: RE: Location of SP Session Cache
  • Date: Wed, 30 May 2007 11:05:28 -0400
  • Organization: The Ohio State University

> So far I've encountered a few problems with a memcache StorageService:
>
> - Key size. Memcache's max key size is 250 chars (bytes). I can alter
> memcache and raise it to 256 but more than that requires bigger
> changes and could also break the clients.
>
> - Contexts. Memcache works like a dictionary so it only has one
> level. If the key size was smaller I could use a key like CONTEXT:KEY
> but this way I dont know.. And the context size is not specified as
> well.

I can probably shrink or limit the context, but I can't shrink the key. The
SAML spec has no constraint on the size of an ID, so even the implicit
limitation I have baked in there now is arbitrary. I don't really see that I
have a choice in terms of the API. If you want to just check it and just
reject anything that's too long, that's up to you. It will work in most
every case, but I can't guarantee that.

> - Update Context and Delete Context. Memcache has no API to search as
> it is not a database... So in order to implement this I would have to
> keep in memcache a structure with the list of keys stored by context...

That's why I'm using a database. It's not going to get simpler, the session
cache has to implement lookup by both session key and NameID in order to
support logout. All of that is being buried inside the API, but you have to
support the features. I group session data into a context per session,
that's why I have to have those methods.

And I'll warn you that updating the expiration of the context has to be
fast, you have to do it on every request to enforce inactivity timeouts.

> Also, if we ever get this to work, will it be possible to share this
> cache among various SPs of different applications or will their
> contexts clash?

Depends on the component using it. The session cache uses the session key as
a context, so it's unique. Other contexts probably will have a fixed value
but will be storing non-overlapping data, unless people are generating
conflicting assertion IDs or artifacts. You can search the code to see all
the create calls.

-- Scott





Archive powered by MHonArc 2.6.16.

Top of Page