i was thinking of using it as IDP or sthg close *Romain Manni-Bucau* *Twitter: @rmannibucau* *Blog: http://rmannibucau.wordpress.com*
2012/8/22 Colm O hEigeartaigh <[email protected]> > What kind of integration do you propose? > > Colm. > > On Wed, Aug 22, 2012 at 8:14 AM, Romain Manni-Bucau > <[email protected]>wrote: > > > 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 <[email protected]> > > > > > 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:[email protected]] > > > Envoyé : mardi 21 août 2012 16:48 > > > À : [email protected] > > > 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 [[email protected]] > > > Sent: 21 August 2012 13:28 > > > To: [email protected] > > > 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 <[email protected]> > > > > > > > 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<[email protected]**> > > > >> > > > >> 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<[email protected]****> > > > >>>> > > > >>>> 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<[email protected]******> > > > >>>>>> > > > >>>>>> 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<[email protected]> > > > >>>>>>>> > > > >>>>>>>> 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 [[email protected]] > > > >>>>>>>>> Sent: 17 August 2012 15:13 > > > >>>>>>>>> To: [email protected] > > > >>>>>>>>> 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<[email protected]********> > > > >>>>>>>>> > > > >>>>>>>>> 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. > > > > > > > > > > > > -- > Colm O hEigeartaigh > > Talend Community Coder > http://coders.talend.com >
