Size of client-side sessions

[Cantor, Scott]

On 10/30/13, 3:45 PM, "Marvin S. Addison" <marvin.addison at gmail.com> wrote:
>
>What's the cost of each additional SPSession object? Is there any data
>out there on the number of SP sessions per IdP session so you can get a
>sense on size over time?

It's moot here because I don't store them client-side. The primary use
case for storing them at all is SAML logout, and there are immediate and
self-evident problems with the size there that make it a waste of time to
bother.

It's also much less unbounded than the number of AuthenticationResults is,
but I have no statistics.

With the options to use memcache and a database, sites that really want
logout at some point can simply cluster it, or just do active/passive.

>> Some more shrinking is possible, plus this is using JSON, so it's still
>> text based and could be smaller with a binary encoding.
>
>I learned of MsgPack [1] recently and wanted to mention it. Looked
>promising for use cases where efficiency is preeminent.

I'm doing something similar now, I have a symbolics map you can configure
to collapse long strings into integers, which shrunk it about 50 bytes.
But the gains are minimal because I already GZIP when encryption is done.

The other point is that the storage map itself is separately serialized
for the client and could be made binary even if the actual objects in the
session continue as JSON. That's all very non-optimized code to keep it
simple until there's actually some sign it needs to be improved.

Where I finally ended up though, the client side map doesn't get parsed
into memory or decrypted until something accesses it, or saved back unless
it changes, so I'm hopeful it's fast enough.

I am writing up the Session layer docs now, and then will be providing
some how-to material on how to use the testbed to do some simple testing
of local authentication custom requirements. This is likely 90% of the
work of moving to V3, so I'm pleased that it's basically in a working
state at this stage, long before we ship.

-- Scott