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 how web flow makes it easier). One of the advantages of web flow is that it allows our deployers to hook into the process.
Agreed it doesn't make the features easier to implement. Customization is the value I had in mind. We had some conversation about the best way to implement stronger authentication of the peer that presents a ticket for validation (SEC_6): server cert validation, client cert validation, symmetric encryption. With a pluggable approach a deployer could easily swap out an alternative implementation. (I plugged for client certs since this is exactly what we will be doing for Virginia Tech and I know it scales well.)
3. Do you mean deferring lookup until a service needs it?
That's one possibility. I had in mind to re-implement the current behavior of caching attributes for the duration of the SSO session as one particular strategy, with on-demand as the another. It would be up to deployers to enable the desired behavior as a part of install-time configuration. We could also easily plug in additional capabilities like attribute transforms into the validation flow. The ability to grow features and swap/extend behaviors is the (huge) value add we get from webflow.
M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
