Size of client-side sessions

[Cantor, Scott]

On 10/31/13, 10:20 AM, "Rod Widdowson" <rdw at steadingsoftware.com> wrote:
>
>Firstly, with respect to identity switching: I note that this is
>explicitly
>*not* treated as a failure and I'm guessing that this is because it is not
>the principal's fault that the identity has switched.  Thus to fail
>anything
>would be wrong.  I assume that something would be logged, and AFAICS the
>way
>that the design works is that things "just work".

Well, I asked on the list if anybody could think of a scenario in which
the appropriate response would be other than trashing the original session
and just creating a new one. Nothing was suggested, other than my own note
that one could maybe imagine doing some kind of back channel logout behind
the scenes.

So I took out the extra indirection of handling that event and just
created a flow action to handle the problem. If somebody wanted to handle
it differently, that action can be replaced.

I'm trying to balance having a lot of plugin points against keeping things
sane.

>Secondly I tried to fit some of the (SAML) flows that I understand into
>this
>framework and it all "just works" (no surprise), except I am unsure how
>Attribute Query fits in.

I don't know either.

> You explicitly do not mentioned as a motivation for
>much of the session resolver complexity although the NameID->Session
>mapping
>seems to be exactly what is needed.

I'm of two minds about the wisdom of exposing sessions in the context of
an attribute query. This makes it possible, yes, but I have always felt
that was somewhat questionable. It also would make it necessary to have
the secondary index maintained just for attribute queries, and that would
make server-side state a requirement for them, whereas today it's largely
not.

>  Therefore I am assuming that it is
>dealt with in some other way.  We did discuss for a while treating
>NameID->Session as an Authentication flow, is that the idea here?

No. We had talked about maybe recovering the principal name using the
SubjectCanonicalization process, and we can still do that.

>As a very minor question, is the SAMLContext targeted at the HoK profile
>(which I only skimmed and a long time ago) or is that different again?

It's not really targeted at anything right now, it's just there for
completeness. Probably the delegation flow would use it.

>As you have been working on cookie storage (congratulations on the size by
>the way, and also the bit where by update and recovery can happen without
>writing the record) I have been thinking about the whole issue of session
>cookie non destruction on browser shutdown.  I was vaguely convinced that
>by
>putting a date into the cookie something magical could be done to age out
>old cookies and hence sessions (i.e. have another layer of control at
>that,
>lowest, level).  Having read and partially digested the Session document
>it
>seems that I was wrong:  There is more than enough control in the Session
>layer to age out sessions making the need to control this at a lower level
>redundant.

The problem with sticking a date in the cookie is that it means that the
cookie survives restarts on *every* client, regardless of browser. It
takes a problem that affects Firefox and Chrome and makes it a global one.
You can certainly make a case that consistently bad behavior is better
than inconsistency. But I haven't come around yet.

>I suppose that there is a question though:  Do you believe there is
>anything
>we can do in the IdP Design to handle these sorts of buggy browsers?  It
>strikes me that your idea of being able to say "And here are all the
>Sessions you have not been logged out of" might be useful - even if just
>for
>didactic purposes.

That was a use case, yes.

I think the only thing we can do is implement logout, demonstrate once and
for all that it doesn't solve the problem, and maybe get more people
willing to bring pressure. Right now, we're viewed as the problem, which I
take extreme issue with.

-- Scott