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 actually make this situation better?
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. If we think there's a huge potential for deployers to hook into validate then this makes sense, if we just want to add more steps, I don't see how/why we would need to use web flow. Otherwise I enjoy the compile time safety of defining the flow in Java :-) 3. Do you mean deferring lookup until a service needs it? Can't we just plug an instance of PersonDirectory into CentralAuthenticationServiceImpl and do a lookup from there (rather than say storing the attributes on the Principle?) On Mon, Sep 16, 2013 at 9:32 AM, Marvin S. Addison <marvin.addi...@gmail.com > wrote: > 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, SEC_6, and SEC_8 [1] as components/flow states in CAS > protocol validation flow > - Implement on-demand attribute query/release > > I'm confident that in addition to implementing new features, a number of > problem areas in the code base (i.e. argument extractors) could be cleaned > up. > > This could possibly be a 4.1 scope design feature if we try to keep it > tight, otherwise 5.x. > > We will leverage this approach to implement a high-assurance form of > attribute release for Virginia Tech using client certificates to address a > requirement we have locally. If we get to it before the project generally, > I'll provide feedback from the work. > > Best, > M > > [1] https://wiki.jasig.org/**display/CAS/Proposals+to+** > mitigate+security+risks<https://wiki.jasig.org/display/CAS/Proposals+to+mitigate+security+risks> > > -- > 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
