cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cabrera Juan Manuel <Juan-Manuel.Cabr...@atos.net>
Subject RE: Fediz IDP refactored
Date Mon, 03 Dec 2012 14:10:13 GMT
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:coheigea@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 <owulff@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.

Mime
View raw message