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.
