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.org<mailto: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", this forked delivery contains a starting point for "full" federation by supporting WS Federation 'whr' query parameter : * which could be directly provided by the remote/requestor browser, * or selected by the remote user in local/resource IDP's 'signinform.jsp' (among available partners realms registered : see 'IDPPartners.xml' file) if not provided. On RP side, this feature requires a 'HomeRealmCallbackHandler' class (provided in this delivery) configured in 'fediz_config.xml' to intercept the 'whr' query parameter. It works on my side but currently I have not added dedicated integration tests. Have all a good WE ! -----Message d'origine----- De : Daniel Kulp [mailto:dk...@apache.org] Envoyé : lundi 14 janvier 2013 21:48 À : dev@cxf.apache.org<mailto:dev@cxf.apache.org>; Oliver Wulff Objet : Re: Fediz IDP refactored On Jan 14, 2013, at 3:41 PM, Oliver Wulff <owu...@talend.com<mailto:owu...@talend.com<mailto:owu...@talend.com<mailto: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<mailto:dev@cxf.apache.org<mailto:dev@cxf.apache.org<mailto: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<mailto:dev@cxf.apache.org<mailto:dev@cxf.apache.org<mailto: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<mailto:dk...@apache.org<mailto:dk...@apache.org<mailto:dk...@apache.org>> - http://dankulp.com/blog 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.