RE: Fediz IDP refactored, next steps
Patch applied. Thanks Thierry. From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 12 April 2013 15:48 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored, next steps New patch has been added to https://issues.apache.org/jira/browse/FEDIZ-41 to achieve Spring Security and Spring Web Flow integrated to CXF-Fediz. 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.
RE: Fediz IDP refactored, next steps
New patch has been added to https://issues.apache.org/jira/browse/FEDIZ-41 to achieve Spring Security and Spring Web Flow integrated to CXF-Fediz. 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.
RE: Fediz IDP refactored, next steps
Thanks Oli, Ok, your suggestion sounds to me very interesting. It would provide a more declarative way to configure the IDP and probably would reduce the flow complexity. I started to explore this track on basis of your patch. I will attempt to rebuild the flow in compliance with this patch. Thanks Thierry -Message d'origine- De : Oliver Wulff [mailto:owu...@talend.com] Envoyé : mercredi 3 avril 2013 17:24 À : dev@cxf.apache.org Objet : Fediz IDP refactored, next steps All, The Fediz IDP got refactored to leverage the flow management capabilities provided by spring web flow (see https://issues.apache.org/jira/browse/FEDIZ-41) Thanks Thierry for the contribution! I'd like to do one improvement before starting with https://issues.apache.org/jira/browse/FEDIZ-3. Instead of implementing our own spring webflow actions to handle different authentication mechanism we should use spring security instead as this will provide more authentication features to the Fediz IDP (basic auth, form based, etc). We can still use the STS to do the authentication as Spring Security provides customization for username/password validation. What do you think? Thanks Oli 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.
Fediz IDP refactored, next steps
All, The Fediz IDP got refactored to leverage the flow management capabilities provided by spring web flow (see https://issues.apache.org/jira/browse/FEDIZ-41) Thanks Thierry for the contribution! I'd like to do one improvement before starting with https://issues.apache.org/jira/browse/FEDIZ-3. Instead of implementing our own spring webflow actions to handle different authentication mechanism we should use spring security instead as this will provide more authentication features to the Fediz IDP (basic auth, form based, etc). We can still use the STS to do the authentication as Spring Security provides customization for username/password validation. What do you think? Thanks Oli
RE: Fediz IDP refactored
Hi Thierry OK, I understand what you mean. It's the differentiation between requestor idp and resource idp. There can even be scenarios where there are three idps (three redirects and posts) involved. What I'd like to achieve at some stage is, that you can create several logical idp instances within the idp like a resource idp and maybe two requestor idps. You define a URI (ex. /fediz-idp/residp), can configure the type of IDP like Requestor or Resource. The latter means, some home realm discovery mechanism must be in place which should be very flexible. Based on IPs, based on a list, based on the whr parameter sent as part of the redirect, etc. Thus, for simplicity reasons, one idp instance would be sufficient with maybe three entry points like: /fediz-idp/resource /fediz-idp/requestorA /fediz-idp/requestorB In a real production deployment it could still be the case that resource IDP is separated from the requestorA and requestorB IDP. In the STS, you can define three realms like (as an example): 1) fed 2) realmA 3) realmB You can then define the federation relationships in the STS like realmA - realmB (IdentityMapper, which means the user principal is mapped to another one) realmB - realmA (IdentityMapper) realmA - fed (ClaimsMapper, the identity is not mapped but the claims are transformed) realmB - fed (ClaimsMapper) http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/src/main/java/org/apache/cxf/sts/token/realm/Relationship.java?view=markup and here a unit test: http://svn.apache.org/viewvc/cxf/trunk/services/sts/sts-core/src/test/java/org/apache/cxf/sts/operation/IssueSamlClaimsUnitTest.java?view=markup A Relying Party can decide (FederationMetadata document) who its STS URL is, if it is fed, then only the claims from realmA or realmB are mapped. If it's realmA, then the user principal from realmB is mapped to realmA if the relying party has got a dependency on the user id of realmA. The latter might be used initially whereas the former is the true (IMHO) federation use case where authorization is done based on the attributes/claims of the user which were mapped from the attributes of the trusted requestor IDP (which might be another B2B company). I describe this scenario here: http://owulff.blogspot.ch/2012/03/ws-federation-across-several-companies.html WDYT? I've got one question for you: * The requestor's browser doesn't add the 'whr' parameter to the request : the resource RP redirects to the resource IDP/STS to ask the user for selecting his/her home realm (specification § 13.3 step 3.1); this is done in fediz-idp project's 'signinform.jsp' and based on 'idpPartnersUrls' list bean in 'IDPPartners.xml', * The requestor's browser adds the 'whr' parameter to the request : the resource RP can directly redirect to the requestor IDP/STS in order to fill credentials (specification § 13.3 step 5.1). You mention the requestor's browser doesn't add... well... it's the RP which adds this parameter as part of the redirect. Finally, do you think this forked delivery is eligible, as such, for a pull request? I like the design you have chosen. IMHO, I think we (and especially you) can add much faster further improvements to the idp as there are still a lot of things to do. WDYT? Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 21 January 2013 13:12 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored Hi Oliver, Below my answer to your question about difference between IDP and IDP Remote. About yours interesting suggestions related to ApplicationService Bean and IDP configuration GUI I plan to have a meeting with Juan Manuel Cabrera as soon as possible. In my delivery IDP/STS and IDP/STS Remote are not quite different. I only attempted to provide a starting point to illustrate § 13.3 Detailed Example of Web Requester Syntax of http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002 Besides, I would be very interested if you could validate this point. For me, IDP/STS Remote is nothing more than the requestor's IDP/STS owning the Identity of the requestor user. The difference is only matter of configuration. Assuming the request to the resource IDP/STS is done by a requestor user related to a different home realm (see 'passwords.xml' and 'userClaims.xml' in 'fediz-idp-sts-remote' project), there are two use cases : * The requestor's browser doesn't add the 'whr' parameter to the request : the resource RP redirects to the resource IDP/STS to ask the user for selecting his/her home realm (specification § 13.3 step 3.1); this is done in fediz-idp project's 'signinform.jsp' and based on 'idpPartnersUrls' list bean in 'IDPPartners.xml', * The requestor's
RE: Fediz IDP refactored
btw, this is my google talk id: ownaish Thanks From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 21 January 2013 13:12 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored Hi Oliver, Below my answer to your question about difference between IDP and IDP Remote. About yours interesting suggestions related to ApplicationService Bean and IDP configuration GUI I plan to have a meeting with Juan Manuel Cabrera as soon as possible. In my delivery IDP/STS and IDP/STS Remote are not quite different. I only attempted to provide a starting point to illustrate § 13.3 Detailed Example of Web Requester Syntax of http://docs.oasis-open.org/wsfed/federation/v1.2/os/ws-federation-1.2-spec-os.html#_Toc223175002 Besides, I would be very interested if you could validate this point. For me, IDP/STS Remote is nothing more than the requestor's IDP/STS owning the Identity of the requestor user. The difference is only matter of configuration. Assuming the request to the resource IDP/STS is done by a requestor user related to a different home realm (see 'passwords.xml' and 'userClaims.xml' in 'fediz-idp-sts-remote' project), there are two use cases : * The requestor's browser doesn't add the 'whr' parameter to the request : the resource RP redirects to the resource IDP/STS to ask the user for selecting his/her home realm (specification § 13.3 step 3.1); this is done in fediz-idp project's 'signinform.jsp' and based on 'idpPartnersUrls' list bean in 'IDPPartners.xml', * The requestor's browser adds the 'whr' parameter to the request : the resource RP can directly redirect to the requestor IDP/STS in order to fill credentials (specification § 13.3 step 5.1). I nevertheless draws attention to the fact that there is still no integration tests for this feature. Finally, do you think this forked delivery is eligible, as such, for a pull request? Regards -Message d'origine- De : Oliver Wulff [mailto:owu...@talend.com] Envoyé : dimanche 20 janvier 2013 15:34 À : dev@cxf.apache.org Objet : RE: Fediz IDP refactored Hi Thierry This looks really good. What is the difference between IDP and IDP remote? I think we should improve our configurations around the RPClaims.xml. What do you think about introducing an ApplicationService Bean where you can reference (file://, http://) a WS-Federation Metadata document where either the information from the Fediz Plugin is loaded (signature validation), or a local metadata document can be loaded. Properties which are not covered by WS-Federation Metadata are set a setter/getters in the ApplicationServiceBean (ex. tokenType, encryptToken, default home realm, etc). This leads to another question. Right now, everything is configured in spring configuration files where the following actions require a restart of the idp/sts: - add a new application - add a new trusted IDP (like configure a new requestor idp in the resource idp) - etc. I was thinking that a GUI for the IDP would be really nice where you can configure the applications etc. As the spring configuration is static, we could store this information in a database and add it to the spring context dynamically during startup and after a change. Of course, some part are related to the STS as well. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 18 January 2013 17:29 To: dev@cxf.apache.orgmailto:dev@cxf.apache.org Subject: RE: Fediz IDP refactored Hi all, Thanks for your remarks. As Dan suggested, I have forked from https://github.com/apache/cxf-fediz to https://github.com/tbrgit/cxf-fediz last night (then after Colm commit # ef9a0fe5b8fecea18cce0eec3f2116e4aa51663f) Below is the brief summary of changes and enhancements compared to first draft patch delivery : * Missing legal headers added * Compliance with Checkstyle and PMD rules * Useless SafeDispatcherServlet class Oliver pointed me out removed * Major refactoring of federation-webflow.xml * Chained protocol-oriented checks decision states have been merged in one * transitions on-exception ... / have been reviewed * The whole now runs with integration tests (Jetty and Tomcat) for BASIC authentication * with refactoring of systests-jetty8 pom.xml -- maven-dependency-plugin 'unpack' goal instead of 'copy' to be compliant with systests-tomcat7 * with minor changes to systests-jetty8 jetty/idp-server.xml and jetty/rp-server.xml -- to be equivalent to systests-tomcat7 target structure * bug related to http return code 500 which should be 401 is fixed on my side (@Ignore uncommented) * Note: I plan to add corresponding integration tests for FORM authentication More, as a cherry on the cake
RE: Fediz IDP refactored
Hi there I had a look into it and it looks to be a really good starting point. As you wrote, it is not yet complete. But there is still a lot of stuff to do. Due to the fact that you and maybe some others will have to commit updates to it it might be easier to have a mirror a github thus you can commit as well. When it is close to be complete I can merge it into the idp project at apache. Could you add the missing licensing header? Make the modifications to the idp project itself thus the maven checkstyle are validated as there are some formatting issues. Not sure about SafeDispatcherServlet as it looks to be from CAS. What do you think? I would also like to incorporate spring-security into it thus we can leverage the existing authentication mechanisms provided by it. But one step after the other. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Oliver Wulff [owu...@talend.com] Sent: 08 January 2013 20:20 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored Thanks Thierry. I'll look into this asap. Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 08 January 2013 17:52 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored A new post about 'Fediz IDP refactored with Spring Web Flow' has been added to Fediz JIRA repository. at https://issues.apache.org/jira/browse/FEDIZ-41 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.
RE: Fediz IDP refactored
btw, I've set up some integration tests for fediz, where the idp/sts is started in a container (tomcat/jetty) as the application in a separate container. The integration tests run several tests against the two. Thus you can easily test against the refactored idp. http://svn.apache.org/viewvc/cxf/fediz/trunk/systests/ -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Oliver Wulff [owu...@talend.com] Sent: 14 January 2013 21:41 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored Hi there I had a look into it and it looks to be a really good starting point. As you wrote, it is not yet complete. But there is still a lot of stuff to do. Due to the fact that you and maybe some others will have to commit updates to it it might be easier to have a mirror a github thus you can commit as well. When it is close to be complete I can merge it into the idp project at apache. Could you add the missing licensing header? Make the modifications to the idp project itself thus the maven checkstyle are validated as there are some formatting issues. Not sure about SafeDispatcherServlet as it looks to be from CAS. What do you think? I would also like to incorporate spring-security into it thus we can leverage the existing authentication mechanisms provided by it. But one step after the other. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Oliver Wulff [owu...@talend.com] Sent: 08 January 2013 20:20 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored Thanks Thierry. I'll look into this asap. Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 08 January 2013 17:52 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored A new post about 'Fediz IDP refactored with Spring Web Flow' has been added to Fediz JIRA repository. at https://issues.apache.org/jira/browse/FEDIZ-41 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.
Re: Fediz IDP refactored
On Jan 14, 2013, at 3:41 PM, Oliver Wulff owu...@talend.com wrote: Hi there I had a look into it and it looks to be a really good starting point. As you wrote, it is not yet complete. But there is still a lot of stuff to do. Due to the fact that you and maybe some others will have to commit updates to it it might be easier to have a mirror a github thus you can commit as well. When it is close to be complete I can merge it into the idp project at apache. Yep. All that CXF projects have git mirrors at Github already: https://github.com/apache/cxf-fediz that you can fork from. Also, if you issue a pull request, the notice should get sent right to this list at which point we can review and pull if appropriate. Dan Could you add the missing licensing header? Make the modifications to the idp project itself thus the maven checkstyle are validated as there are some formatting issues. Not sure about SafeDispatcherServlet as it looks to be from CAS. What do you think? I would also like to incorporate spring-security into it thus we can leverage the existing authentication mechanisms provided by it. But one step after the other. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Oliver Wulff [owu...@talend.com] Sent: 08 January 2013 20:20 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored Thanks Thierry. I'll look into this asap. Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 08 January 2013 17:52 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored A new post about 'Fediz IDP refactored with Spring Web Flow' has been added to Fediz JIRA repository. at https://issues.apache.org/jira/browse/FEDIZ-41 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. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
RE: RE: Fediz IDP refactored
Hi. I wish you all a happy new year, may it bring you the best. I trust that the patch Thierry provided with Spring Webflow will help smoothen future developments on the IDP, since the codebase is reduced a lot and the flow is cleaner (at least imo). @Oli: Would you like me or Thierry to file a JIRA with this patch enclosed instead of publishing it in the mailing list? Meanwhile, we kept ourselves busy doing some developments to address the remote IDP usecase (see FEDIZ-3https://issues.apache.org/jira/browse/FEDIZ-3) We are now working on translating this towards Spring Webflow. As soon as this is done, we will provide a patch on the aforementioned issue if this is OK for you. Regards, Juan Manuel From: Beucher Thierry Sent: Monday, January 07, 2013 5:08 PM To: dev@cxf.apache.org Cc: Cabrera Juan Manuel; Monteiro Jean-Louis Subject: RE: Fediz IDP refactored Hi, As Juan Manuel Cabrera suggested, I completely refactored Fediz idp component basing on Spring WebFlow : it can be found as attached fediz-idp-swf.patch. Basically the idea was to remove complex chain of filters implementing the idp flow, drastically reducing the base code. Applying the patch, all filters are removed and the master logic is migrated to federation-webflow.xml. It implies main other changes : * web.xml : referencing new idp servlet handling web-flow and mapped to /federation relative URL, * new idp-servlet.xml including web-flow configuration and specific idp beans configuration (which sources can be found into org.apache.cxf.fediz.service.idp.beans package), * various new and modified jsp views invoked as SWF view or end states in flow (signinform.jsp, signinresponseform.jsp, signoutresponse.jsp, genericerror.jsp and blank.jsp) The patch supports the following features, as currently implemented in original fediz-idp 1.1.0-SNAPSHOT release : * Login * Logout * Basic authentication and Form authentication (switch from one to the other has currently to be set in federation-webflow.xml) The patch has been successfully tested with singleWebapp project and webapp fedizservice projects. Note: the only change required for Relying Parties webapps is located in fediz-config.xml : the protocol issuer should no longer be issuerhttps://localhost:9443/fedizidp//issuerhttps://localhost:9443/fedizidp/%3c/issuer but issuerhttps://localhost:9443/fedizidp/federation/issuerhttps://localhost:9443/fedizidp/federation%3c/issuer All remarks will be welcomed... Regards 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.
RE: Fediz IDP refactored
A new post about 'Fediz IDP refactored with Spring Web Flow' has been added to Fediz JIRA repository. at https://issues.apache.org/jira/browse/FEDIZ-41 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.
RE: Fediz IDP refactored
Thanks Thierry. I'll look into this asap. Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Beucher Thierry [thierry.beuc...@atos.net] Sent: 08 January 2013 17:52 To: dev@cxf.apache.org Subject: RE: Fediz IDP refactored A new post about 'Fediz IDP refactored with Spring Web Flow' has been added to Fediz JIRA repository. at https://issues.apache.org/jira/browse/FEDIZ-41 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.
RE: Fediz IDP refactored
Hi, As Juan Manuel Cabrera suggested, I completely refactored Fediz idp component basing on Spring WebFlow : it can be found as attached fediz-idp-swf.patch. Basically the idea was to remove complex chain of filters implementing the idp flow, drastically reducing the base code. Applying the patch, all filters are removed and the master logic is migrated to federation-webflow.xml. It implies main other changes : * web.xml : referencing new idp servlet handling web-flow and mapped to /federation relative URL, * new idp-servlet.xml including web-flow configuration and specific idp beans configuration (which sources can be found into org.apache.cxf.fediz.service.idp.beans package), * various new and modified jsp views invoked as SWF view or end states in flow (signinform.jsp, signinresponseform.jsp, signoutresponse.jsp, genericerror.jsp and blank.jsp) The patch supports the following features, as currently implemented in original fediz-idp 1.1.0-SNAPSHOT release : * Login * Logout * Basic authentication and Form authentication (switch from one to the other has currently to be set in federation-webflow.xml) The patch has been successfully tested with singleWebapp project and webapp fedizservice projects. Note: the only change required for Relying Parties webapps is located in fediz-config.xml : the protocol issuer should no longer be issuerhttps://localhost:9443/fedizidp//issuerhttps://localhost:9443/fedizidp/%3c/issuer but issuerhttps://localhost:9443/fedizidp/federation/issuerhttps://localhost:9443/fedizidp/federation%3c/issuer All remarks will be welcomed... Regards 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.
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 [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.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com
RE: Fediz IDP refactored
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:owu...@talend.com] Sent: Friday, December 14, 2012 4:54 PM To: dev@cxf.apache.org; cohei...@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 [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
RE: Fediz IDP refactored
Hi Sergey Yes, this is planned. Initially, I move some classes from the fediz examples to the cxf plugin as they are always the same (CallbackHandler etc.). Additionally, an interceptor is added for JAX-RS endpoints to trigger the redirect to the IDP to get the saml token. Thanks Oli -- Oliver Wulff Blog: http://owulff.blogspot.com Solution Architect http://coders.talend.com Talend Application Integration Division http://www.talend.com From: Sergey Beryozkin [sberyoz...@gmail.com] Sent: 03 December 2012 16:22 To: dev@cxf.apache.org Subject: Re: Fediz IDP refactored Hi I was also planning to ask, if CXF plugin were to be added too, how will it work with such a plugin ? Cheers, Sergey 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.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend 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. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
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.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend 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
Re: Fediz IDP refactored
Hi I was also planning to ask, if CXF plugin were to be added too, how will it work with such a plugin ? Cheers, Sergey 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.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend 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. -- Sergey Beryozkin Talend Community Coders http://coders.talend.com/ Blog: http://sberyozkin.blogspot.com
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.comhttp://owulff.blogspot.com/ Solution Architect http://coders.talend.com http://coders.talend.comTalend Application Integration Division http://www.talend.com -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
