Message contexts and Spring Webflow conversation scope

[Brent Putman]

On 2/27/13 9:11 PM, Tom Zeller wrote:
> What do you make of this from the spring docs :
>
> "With the default implementation, conversation scoped objects are
> stored in the HTTP session and should generally be Serializable to
> account for typical session replication." [1]

I think it was something like that that originally triggered the alarm
when I looked at this a long time ago.  The "generally" there is a
little vague to an uninformed reader, but I think it's basically
consistent with what Scott said earlier: it's really actually a function
of what the container impl does with HttpSession.


> Do you know what class in web flow is the default impl ?

Yeah, there's only 1 of each.  SessionBindingConversationManager
implements ConversationManager, and ContainedConversation implements
Conversation.

The latter is just a container for the attributes and implements
Serializable (implying that any attributes you store must also
implement), and the former does the obvious: just handles storing and
retrieving that container class in the HttpSession (indirectly via the
ExternalContext).



>
> Just a comment that I think web flow is still officially
> on-the-table-for-discussion until we increase our expertise and
> experience, especially in a production environment, like Scott's :-)


Sure.  I suppose this is then one of the things that we need to validate
in order to say go or no-go for Webflow.


>
>> I propose that we get these impls done and actually tested in a running
>> Webflow environment as soon as possible.  I suppose it's probably a Tom
>> thing, since it's in the IdP, but it's also a critical part of the
>> message processing design, so I can also take it on if Tom doesn't have
>> the time or interest.  Would also give me an opportunity to get some
>> hands-on experience with Webflow.
> I would rather have web flow partners than fly solo.
>
> As far as timing ... I switched from web flow to spring, sort of
> waiting on Phil. Maybe we could punt on web flow until next month and
> parallelize our efforts ?

That's fine with me, I mainly just wanted to suggest we validate this
before we get too far into committing down the Webflow path.

> How would this fit into your opensaml v3 work ?

It's really orthogonal to the technical OpenSAML design itself, but it's
related to the whole issue of design of message processing in the IdP,
which is why it occurred to me.