1. by doing this are we spreading the protocol-specific logic into too
many places?
I don't see that as a given outcome of use of webflow. It's arguably too
soon to say whether it makes isolation of concern better or worse.
2. I don't think 4/6/8 require web flow to implement (nor do I see h
I think for me it comes down to our usual discussion:
1. are we exposing extension/plugin points (i.e. swap cert validation,
etc.) or
2. are we exposing a completely customizable flow (i.e. login)
If we can get away with #1, then we get the advantages of well defined
supported APIs and guaranteed
I'm not against leveraging web flow more, but have a few comments:
1. by doing this are we spreading the protocol-specific logic into too many
places? Arguably, its already leaked into a few too many areas where its
not clear what you have to do to add a new protocol. Do you think web flow
would
Another thought I've been having for sometime is the need to decouple
primary authentication from CAS protocol implementation via something
like a Service Provider interface. Seems like the move to more fully
embrace SWF might help here as well.
On Mon, Sep 16, 2013 at 9:32 AM, Marvin S. Addison
Spring Webflow has arguably been one of the best design decisions for
CAS. Building on that strength, we could implement a number of valuable
features related to ticket validation as one or more webflows:
- Implement protocol dispatcher to call into protocol-specific subflows
- Implement SEC_4
