I've raised JIRA for form based authentication support: https://issues.apache.org/jira/browse/FEDIZ-36
Will apply your patch. Works fine for me. Will add configuration option for the signin jsp. ________________________________________ From: Oliver Wulff [owu...@talend.com] Sent: 05 December 2012 21:26 To: dev@cxf.apache.org; cohei...@apache.org Subject: RE: Fediz IDP refactored Hi Juan First, agreed, the IdpServlet is not required anymore. You bring up an interesting idea with spring webflow. During the refactoring I was thinking whether I could re-use all the authentication mechanism supported by Spring security and integrate that into the filter where the authentication mechanism decision is made (based on wauth parameter or other means). I don't have much experience with spring webflow but as far as I know it's finally also a state machine with the addional capability to control the order of the processing units whereas the ServletFilter order is given at deployment time. Do you think we need this flexiblity? In the documentation of spring webflow, they talk about view-state only which we don't have as the authentication itself would be handled by spring security and further processing initially has no user interaction. I'd appreciate if you could start with a version of the IDP using spring webflow. Another benefit of spring webflow is when the IDP provides more user interfaces like a page where you see you're logged in or to trigger the single logout, etc. Thanks Oli ------ Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com ________________________________________ From: Cabrera Juan Manuel [juan-manuel.cabr...@atos.net] Sent: 03 December 2012 15:10 To: dev@cxf.apache.org; cohei...@apache.org Subject: RE: Fediz IDP refactored Hi all. I have done a quick (filter + jsp) to allow for http-form-based authentication. This works great, and is a breathe do be done. Nevertheless, I do think that we need a flow engine (e.g. spring-webflow) more than a state machine. This would to allow for a more flexible combination of operations incl. exceptions recovery (and as a side effect would allow for calling a given state for different "initial states"). In my filter, for instance, if a user enters a bad login/pwd, the STSClientFilter throws a ProcessingException, but I have no real mean to deal with this. Of course, I can override the doFilter method but doing so would defeat the purpose of your state machine. We can think of another method to catch these errors, but again is this not a reimplementation of a workflow engine ? Apart from that, I too think that the IdpServlet could be removed altogether. Kind regards Juan Manuel -----Message d'origine----- De : Colm O hEigeartaigh [mailto:cohei...@apache.org] Envoyé : jeudi 29 novembre 2012 16:03 À : dev@cxf.apache.org Objet : Re: Fediz IDP refactored Hi Oli, > I've refactored the Fediz IDP and I'd like your feedback. The IDP is based on a state machine which re-uses Servlet Filters to build up > the processing chain but an abstract AbstractAuthFilter handles all > the state related processing. +1 - looks good to me. Is there any reason to keep the IdpServlet around any longer? > Another topic I'd like your opinion is the pre-state condition. A > filter is called only if the one state condition is met. If a filter could > support depending on different states, there is also only one FederationFilter needed. I guess it would be more flexible to be able to call a filter if all (or some) of a number of conditions are all met - it might be more complex than is required though? Colm. On Tue, Nov 27, 2012 at 8:24 PM, Oliver Wulff <owu...@talend.com> wrote: > Hi there > > I've refactored the Fediz IDP and I'd like your feedback. The IDP is > based on a state machine which re-uses Servlet Filters to build up the > processing chain but an abstract AbstractAuthFilter handles all the > state related processing. > > I was struggeling a little bit how to define the states. An enum is to > static whereas a string to error prone. I'd like that users have the > option to extend the IDP without having to patch the enum class to > introduce new states. > > I've defined the default states in a enum but all processing is based > on strings. > > It's now much easier to add the SAML profile as only the > FederationFilter and FederationPostFilter has to be rewritten. > > Another topic I'd like your opinion is the pre-state condition. A > filter is called only if the one state condition is met. If a filter > could support depending on different states, there is also only one > FederationFilter needed. > > Looking forward for your feedback. > > Thanks > Oli > > > > > ------ > > Oliver Wulff > > Blog: http://owulff.blogspot.com<http://owulff.blogspot.com/> > Solution Architect > http://coders.talend.com > > <http://coders.talend.com>Talend Application Integration Division > http://www.talend.com > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com Ce message et les pièces jointes sont confidentiels et réservés à l'usage exclusif de ses destinataires. Il peut également être protégé par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir immédiatement l'expéditeur et de le détruire. L'intégrité du message ne pouvant être assurée sur Internet, la responsabilité d'Atos ne pourra être recherchée quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'expéditeur ne donne aucune garantie à cet égard et sa responsabilité ne saurait être recherchée pour tout dommage résultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
