Hi Thierry I got systests running now. I had to do the following changes: - fediz_config.xml adds the trust to the new signer cert of realm - fediz_config.xml enforces home realm "realm-A" - stsstore.jks contains signer cert of realm-A as well - idp must use basic authentication (as the test rely on that)
I've attached the update of the patch (FEDIZ-3.20130725.patch) in JIRA which contains: - profiles to build idp realm-a and realm-b - fixes thus systests run successfully What I think is that we should add some unit tests for the idp itself where we can test the behaviour of depending on the signin parameters created by the unit test like: - homerealm - wfresh - invalid parameter - wauth - wctx - no wreply parameter Do you have already some ideas about the issues I discovered? 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 Sent: 24 July 2013 13:02 To: [email protected] Subject: RE: Fediz IDP webflow Hi Thierry I started testing the new IDP functionality. I made some improvements first to be able to build a war for the IDP "realm-A" and a war for the remote/trusted IDP "realm-B" using profiles (mvn clean install -Prealm-b). "realm-A" is the default. Also the "realm" profile for the STS is the default (systests). I didn't get the systests running yet. As soon as this works I can commit the changes. I've run the following tests: 1) Clear all cookies. RP doesn't enforce a home realm -> Browser user can choose If I choose realm A (no redirect to remote IDP), I can login with bob/bob or alice/ecila Finally, the user "bob" is displayed on the web page of fedizhelloworld 2) Clear all cookies. RP doesn't enforce a home realm -> Browser user can choose If I choose realm B (redirect to remote IDP happens), I can login with BOB/BOB or ALICE/ECILA Finally, the user "bob" (!) is displayed on the web page of fedizhelloworld The trust between realm A and realm B is based in identity federation (the identity is mapped, for ease of use, user ids are uppercase in realm b and lowercase in realm a. 3) After successful login to fedizhelloworld (choosen home realm is realm A), I clear the cookie for the RP. When I access the RP, I get redirected to the configured IDP but no user/password challenge occurs. Instead, new token is issued and I'm logged in to fedizhelloworld. 4) After successful login to fedizhelloworld (choosen home realm is realm B), I clear the cookie for the RP. When I access the RP, I get redirected to the configured IDP but no redirection to remote IDP (realm b) occurs. Instead, new token is issued and I'm logged in to fedizhelloworld. I discovered the following issues: blocking issue: a) If you have chosen a home realm, it is stored in a cookie for this idp (bound to hostname and uri). If the rp defines a home realm (whr parameter in signin request), the home realm is updated. It must not be the case, that an application can overwrite the home realm of a user. An application can just enforce a home realm for the login for this application but this must not have an impact for all other applications. Therefore home realm must not be updated. Major issue: b) If I choose realm B (redirect to remote idp happens), the wctx is used. The form posted to the rp contains the wctx with the same value. After the wctx has been posted to the IDP, it must be cleared. c) If you now clear the cookie with rp, you get redirected and the wctx is still sent to the RP but empty this time. d) the auto submit form is now displayed in the browser (should be disabled by default but the option to enable it for debug purposes would be fine) 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: Oliver Wulff Sent: 23 July 2013 16:55 To: [email protected] Subject: RE: Fediz IDP webflow Hi Thierry Thanks a lot for this contribution. I'll look into it and provide feedback till end of the week. 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 [[email protected]] Sent: 23 July 2013 15:20 To: [email protected] Subject: Fediz IDP webflow Hi, I just contributed to https://issues.apache.org/jira/browse/FEDIZ-3 by adding a new patch that supersedes the one provided by Oliver Wulff. Based on the background code and the configuration provided by O.Wulff, integrating them, this patch offers a new version of webflow supporting delegated authentication : When a user accesses a resource on some RP protected by an IDP which does not make its authentication but which is able to establish a relationship of trust with the IDP where the user is affiliated, the resource IDP may propose to the user to specify the requestor IDP (user's "home realm") to which delegate the authentication phase (if it cannot be determined by others means). Once the requestor IDP proceeded to authentication, it return the requested security token to the resource IDP (acting here as a RP), in such way this one can, in turn, issue another requested security token to RP. Resource and requestor IDPs are both configured with the same common webflow. ________________________________ 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.
