Drafty thoughts on session data structures and storage

[Cantor, Scott]

On 9/19/13 6:55 PM, "Tom Zeller" <tzeller at dragonacea.biz> wrote:
>
>A naming question, why "Service" in ServiceSession ? In IdPv3 a
>Service is a configurable Component, a generic thing, and I was
>expecting ClientSession or RelyingPartySession.

Inherited name, didn't change so far.

I know why he named it that, he was contrasting it with IdPSession. I
think RelyingPartySession is a little wordy (and I don't love the RP term
as a rule), but I'm thinking the simplest thing is just to go with
SPSession as a parallel to IdPSession (or IDPSession, though the common
abbrev. is IdP).

>Why store the flow ID ? I think flow IDs might change, via
>configuration, during a session lifetime.

That's an issue across the authentication and session layer. In this
particular case, I didn't like the idea of connecting the ServiceSession
directly to an AuthenticationResult because that really complicates
serialization and makes the whole structure more complex because you have
this interplay between the collection of results and of svc sessions.

As far as I can see, the only actual use case to hand for even connecting
to a result is to support the attribute filtering function based on
"AuthenticationMethod", which is not very commonly used. For now, I went
with storing the flowID from the result in the svc session as a way to
connect them, with the understanding that if the connection broke because
the flow IDs change, the effect is very minor.

-- Scott