actually i wonder if it makes sense to get an integration with syncope ( http://incubator.apache.org/syncope/features.html )
*Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com* 2012/8/21 Cabrera Juan Manuel <juan-manuel.cabr...@atos.net> > Hello. > > I'm working with Romain on SSO and Fediz subjects in Atos. > For what it's worth, this scenario makes perfect sense to me :) > That would create a clear separation between the sessions of each > application, and a clear opportunity to control more thoroughly the > timespan at which a given application must come back to the IDP to get a > new token; for instance 1 minute long tokens for sensitive applications > would prevent sessions on a sensitive application to survive the death of > the IDP session more than one minute (kind of dirty, nearly-sync, poor > man's single sign out). > > Regards, > Juan Manuel > > > -----Message d'origine----- > De : Oliver Wulff [mailto:owu...@talend.com] > Envoyé : mardi 21 août 2012 16:48 > À : dev@cxf.apache.org > Objet : RE: fediz & SSO? > > > It's correct that the IDP should manage the state and not request > username/password again. I'd like to avoid to cache passwords in a session > for security reasons ;-) > > What do you think about this proposal. For the first login, you request a > SAML token from the STS which is application agnostic. This token has a > longer lifetime and is cached in the IDP session. Everytime the browser > requests a login for an RP, the IDP requests a token for the RP to the STS > onbehalfof the cached SAML token. This token contains the claims and other > information required for the RP. > > Does that make sense to you? > > > ------ > > Oliver Wulff > > Blog: http://owulff.blogspot.com > Solution Architect > http://coders.talend.com > > Talend Application Integration Division http://www.talend.com > > ________________________________________ > From: Romain Manni-Bucau [rmannibu...@gmail.com] > Sent: 21 August 2012 13:28 > To: dev@cxf.apache.org > Subject: Re: fediz & SSO? > > sounds closer to what i was expecting ;) > > *Romain Manni-Bucau* > *Twitter: @rmannibucau* > *Blog: http://rmannibucau.wordpress.com* > > > > > 2012/8/21 Sergey Beryozkin <sberyoz...@gmail.com> > > > On 21/08/12 12:05, Romain Manni-Bucau wrote: > > > >> not sure i get it, > >> > >> currently if you come from another rp that the one which logged in > >> the user it need the password *again* > >> > > > > I guess it confirms IdpServlet is not managing its state yet, > > > > however, as I said, if the next RP application were sharing the state > with > > the original RP application then IdpServlet would not have to be involved > > again; agreed that IdpServlet need to cope with the users already logged > in > > into the *same* application (no matter how many containers that > application > > is running at), but I reckon every individual container can contribute > to a > > 'smoother' experience, by getting the state shared and avoiding > redirecting > > the user to IDP (even if that means that IDP will recognize the user is > > already logged in and redirect him back to RP). > > I have a working OAuth2 demo which does exactly that, multiple containers > > sharing the state, similarly should be possible with the applications > > relaying on Fediz IDP > > > > I think I should keep quiet now and let Oli comment :-). > > > > Sergey > > > > > >> *Romain Manni-Bucau* > >> *Twitter: @rmannibucau* > >> *Blog: http://rmannibucau.wordpress.**com< > http://rmannibucau.wordpress.com> > >> * > >> > >> > >> > >> > >> 2012/8/21 Sergey Beryozkin<sberyoz...@gmail.com**> > >> > >> On 21/08/12 11:53, Romain Manni-Bucau wrote: > >>> > >>> from what i saw (IdpServlet) it doesn't keep it and need the password > >>>> (but > >>>> i maybe missed sthg): > >>>> http://svn.apache.org/repos/****asf/cxf/fediz/trunk/services/****< > http://svn.apache.org/repos/**asf/cxf/fediz/trunk/services/**> > >>>> idp/src/main/java/org/apache/****cxf/fediz/service/idp/**** > >>>> IdpServlet.java<http://svn.**apache.org/repos/asf/cxf/** > >>>> fediz/trunk/services/idp/src/**main/java/org/apache/cxf/** > >>>> fediz/service/idp/IdpServlet.**java< > http://svn.apache.org/repos/asf/cxf/fediz/trunk/services/idp/src/main/java/org/apache/cxf/fediz/service/idp/IdpServlet.java > > > >>>> > > >>>> > >>>> This is what I was saying, IDP manages the actual login and hence it > >>> needs > >>> a user to actually log on (using Basic Auth - password, client cert, > >>> whatever), whereas SP (or RP) applications have to manage the state > which > >>> would let them validate via some back channel (using WS-Fed in Fediz's > >>> case) that the log-in is active... > >>> > >>> IDP need to keep a state of their own in order to let user avoid > entering > >>> the password again, while the session is active, in cases when say the > RP > >>> has been restarted and redirected the user back to IDP to log on, I > guess > >>> IdpServlet can handle that and if not then it could require a minor > >>> update, > >>> but I think, as far as multiple RP applications are concerned and their > >>> state, it's not what IdpServlet itself will manage > >>> > >>> Cheers, Sergey > >>> > >>> > >>> *Romain Manni-Bucau* > >>>> *Twitter: @rmannibucau* > >>>> > >>>> *Blog: http://rmannibucau.wordpress.****com<http://rmannibucau.** > >>>> wordpress.com <http://rmannibucau.wordpress.com>> > >>>> * > >>>> > >>>> > >>>> > >>>> > >>>> 2012/8/21 Sergey Beryozkin<sberyoz...@gmail.com****> > >>>> > >>>> Hi > >>>> > >>>>> > >>>>> On 21/08/12 11:42, Romain Manni-Bucau wrote: > >>>>> > >>>>> well i thought of some distributed solutions but for me that's not > a > >>>>> > >>>>>> solution since you keep the password instead of keeping the token, i > >>>>>> think > >>>>>> the current logic flow is not matching this requirement (but is it a > >>>>>> fediz > >>>>>> requirement?) > >>>>>> > >>>>>> > >>>>>> My understanding that it is only IDP that keeps, indirectly, the > >>>>>> > >>>>> password > >>>>> and the state management at the RP side is all about getting the > login > >>>>> token shared, but I'm not sure yet how Fediz does it, shame I haven't > >>>>> debugged it yet, need to do it asap :-) > >>>>> > >>>>> Cheers, Sergey > >>>>> > >>>>> *Romain Manni-Bucau* > >>>>> > >>>>> *Twitter: @rmannibucau* > >>>>>> > >>>>>> *Blog: http://rmannibucau.wordpress.******com<http://rmannibucau.** > >>>>>> wordpress.com<http://**rmannibucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>> >> > >>>>>> * > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2012/8/21 Sergey Beryozkin<sberyoz...@gmail.com******> > >>>>>> > >>>>>> On 20/08/12 22:17, Romain Manni-Bucau wrote: > >>>>>> > >>>>>> > >>>>>>> two distinct RP webapps (let say in different tomcat). > >>>>>>> > >>>>>>> > >>>>>>>> currently it "almost works" because with 401 the client (browser) > >>>>>>>> will > >>>>>>>> cache authorization header so it will seem it work but since you > >>>>>>>> change > >>>>>>>> the > >>>>>>>> way you login (and the user/pass is no more in headers) it can't > >>>>>>>> work > >>>>>>>> anymore (typically a form). > >>>>>>>> > >>>>>>>> > >>>>>>>> This seems like a state management issue to me. Fediz currently > >>>>>>>> > >>>>>>> relies on > >>>>>>> the servlet container to manage the session state, so if you say > have > >>>>>>> the > >>>>>>> single application running on two Tomcat containers then Tomcat has > >>>>>>> to > >>>>>>> be > >>>>>>> configured to get the state shared between multiple containers, I > >>>>>>> recall > >>>>>>> I > >>>>>>> saw some material on the web on how to do it, > >>>>>>> > >>>>>>> Alternatively, the state can be managed by Fediz itself (similarly > to > >>>>>>> the > >>>>>>> way we do it with Web profile), may be we can support that too once > >>>>>>> CXF-centric extensions are added > >>>>>>> > >>>>>>> Cheers, Sergey > >>>>>>> > >>>>>>> > >>>>>>> The point today is "what's next' in IDP? I mean, does fediz aims > >>>>>>> to > >>>>>>> > >>>>>>> provide > >>>>>>>> extensibility or will user need to fork the IDP to get some custom > >>>>>>>> features > >>>>>>>> (i know the answer will not be yes or no ;), but a state is > >>>>>>>> important > >>>>>>>> IMO)? > >>>>>>>> > >>>>>>>> *Romain Manni-Bucau* > >>>>>>>> *Twitter: @rmannibucau* > >>>>>>>> *Blog: http://rmannibucau.wordpress.********com< > http://rmannibucau. > >>>>>>>> ** > >>>>>>>> wordpress.com<http://**rmannib**ucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>>>> <http://**rmannibucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>>>> > > >>>>>>>> > >>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>>> * > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> 2012/8/20 Oliver Wulff<owu...@talend.com> > >>>>>>>> > >>>>>>>> Hi Romain > >>>>>>>> > >>>>>>>> > >>>>>>>> The IDP has a lot of potential for new features. At the very > >>>>>>>>> beginning, > >>>>>>>>> the Fediz IDP was intended to mock an IDP and test your > application > >>>>>>>>> but > >>>>>>>>> it > >>>>>>>>> has grown as you can meanwhile attach LDAP for authentication and > >>>>>>>>> claims > >>>>>>>>> support. > >>>>>>>>> > >>>>>>>>> I'm not sure what you mean by classical SSO between two web apps? > >>>>>>>>> > >>>>>>>>> Thanks > >>>>>>>>> Oli > >>>>>>>>> > >>>>>>>>> ------ > >>>>>>>>> > >>>>>>>>> Oliver Wulff > >>>>>>>>> > >>>>>>>>> Blog: http://owulff.blogspot.com > >>>>>>>>> Solution Architect > >>>>>>>>> http://coders.talend.com > >>>>>>>>> > >>>>>>>>> Talend Application Integration Division http://www.talend.com > >>>>>>>>> > >>>>>>>>> ______________________________********__________ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> From: Romain Manni-Bucau [rmannibu...@gmail.com] > >>>>>>>>> Sent: 17 August 2012 15:13 > >>>>>>>>> To: dev@cxf.apache.org > >>>>>>>>> Subject: Re: fediz& SSO? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ok, great, so i'll wait some news from fediz ;) > >>>>>>>>> > >>>>>>>>> thanks for the answer > >>>>>>>>> > >>>>>>>>> *Romain Manni-Bucau* > >>>>>>>>> *Twitter: @rmannibucau* > >>>>>>>>> *Blog: http://rmannibucau.wordpress.********com< > >>>>>>>>> http://rmannibucau.** > >>>>>>>>> wordpress.com<http://**rmannib**ucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>>>>> <http://**rmannibucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>>>>> > > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> * > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> 2012/8/17 Sergey Beryozkin<sberyoz...@gmail.com********> > >>>>>>>>> > >>>>>>>>> Hi > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On 17/08/12 09:11, Romain Manni-Bucau wrote: > >>>>>>>>>> > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> i didn't see anything in the roadmap of fediz regarding the > >>>>>>>>>>> 'classical' > >>>>>>>>>>> SSO > >>>>>>>>>>> (between 2 webapps with GUI). > >>>>>>>>>>> > >>>>>>>>>>> It doesn't seem to currently work (well that's not a big > surprise > >>>>>>>>>>> but > >>>>>>>>>>> that's a big problem for real applications which have GUI + > WS). > >>>>>>>>>>> > >>>>>>>>>>> Any information about it? > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Colm and myself worked on implementing SAML SSO Web Profile > >>>>>>>>>>> at > >>>>>>>>>>> the > >>>>>>>>>>> SP > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> side > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> only, currently in CXF, implemented with the help of JAX-RS > >>>>>>>>> > >>>>>>>>> filters/endpoints. I hope we can come to some agreement soon > >>>>>>>>>> enough > >>>>>>>>>> on > >>>>>>>>>> > >>>>>>>>>> how > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> to get it linked with Fediz > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Another question is the GUI used for the login, a 401 is > >>>>>>>>>> rarely > >>>>>>>>>> what > >>>>>>>>>> an > >>>>>>>>>> > >>>>>>>>>> application wants, any way to use a form or is th eonly way > to > >>>>>>>>>> > >>>>>>>>>> achieve > >>>>>>>>>>> > >>>>>>>>>>> it > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> forking the existing servlets? > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> The login form is offered by IDP (Fediz in this case). We've > >>>>>>>>>>> chatted > >>>>>>>>>>> > >>>>>>>>>>> with > >>>>>>>>>> Oli few months ago on providing CXF-centric Fediz extensions, > when > >>>>>>>>>> we > >>>>>>>>>> do > >>>>>>>>>> > >>>>>>>>>> it > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> we will be able to utilize JAX-RS RequestDispatcherProvider > >>>>>>>>> which > >>>>>>>>> > >>>>>>>>> links > >>>>>>>>>> > >>>>>>>>>> the > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> data with JSP/other view handlers - this is how we do SAML SSO > >>>>>>>>> Post > >>>>>>>>> > >>>>>>>>> Redirect support too > >>>>>>>>>> > >>>>>>>>>> Cheers, Sergey > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> *Romain Manni-Bucau* > >>>>>>>>>> > >>>>>>>>>> *Twitter: @rmannibucau* > >>>>>>>>>> > >>>>>>>>>>> *Blog: http://rmannibucau.wordpress.**********com< > >>>>>>>>>>> > >>>>>>>>>>> http://rmannibucau.wordpress.********com<http://rmannibucau > . > >>>>>>>>>>> ** > >>>>>>>>>>> > >>>>>>>>>>> wordpress.com<http://**rmannib**ucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>>>>>> <http://**rmannibucau.wordpress.com< > http://rmannibucau.wordpress.com> > >>>>>>>>>> > > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> * > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> -- > >>>>>>>>>>> > >>>>>>>>>>> Sergey Beryozkin > >>>>>>>>>> > >>>>>>>>>> Talend Community Coders > >>>>>>>>>> http://coders.talend.com/ > >>>>>>>>>> > >>>>>>>>>> Blog: http://sberyozkin.blogspot.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. > >
