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 Fri, 14 Dec 2012 16:19:18 GMT
Great, thanks a lot.

I'm working on the federation support, I'm almmost done.
Expect a patch next week on this subject :)
It will not cover the whole federation though, but I trust that this will be a first interesting
step.

Regards,

Juan Manuel

-----Original Message-----
From: Oliver Wulff [mailto:owulff@talend.com]
Sent: Friday, December 14, 2012 4:54 PM
To: dev@cxf.apache.org; coheigea@apache.org
Subject: RE: Fediz IDP refactored


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 [owulff@talend.com]
Sent: 05 December 2012 21:26
To: dev@cxf.apache.org; coheigea@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.Cabrera@atos.net]
Sent: 03 December 2012 15:10
To: dev@cxf.apache.org; coheigea@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: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.


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