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 execution of behavior (along with the usual issue of people having to wait for a minor release to get a new extension point if we didn't think of something). Obviously #2 leaves everyone up to their own devices to do whatever they want which empowers people but can also cause confusion/support issues and a (potentially) more fragile integration scenario. On Mon, Sep 16, 2013 at 2:28 PM, Marvin S. Addison <marvin.addi...@gmail.com > wrote: > 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 cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/**display/JSG/cas-dev<http://www.ja-sig.org/wiki/display/JSG/cas-dev> > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
