You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cxf.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2012/08/17 10:11:19 UTC
fediz & SSO?
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?
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?
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <co...@apache.org>
> What kind of integration do you propose?
>
> Colm.
>
> On Wed, Aug 22, 2012 at 8:14 AM, Romain Manni-Bucau
> <rm...@gmail.com>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 <Ju...@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:owulff@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 [rmannibucau@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 <sb...@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<sberyozkin@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<sberyozkin@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<sberyozkin@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<ow...@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 [rmannibucau@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<sberyozkin@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.
> > >
> > >
> >
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
Re: fediz & SSO?
Posted by Colm O hEigeartaigh <co...@apache.org>.
What kind of integration do you propose?
Colm.
On Wed, Aug 22, 2012 at 8:14 AM, Romain Manni-Bucau
<rm...@gmail.com>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 <Ju...@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:owulff@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 [rmannibucau@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 <sb...@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<sberyozkin@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<sberyozkin@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<sberyozkin@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<ow...@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 [rmannibucau@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<sberyozkin@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.
> >
> >
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <Ju...@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:owulff@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 [rmannibucau@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 <sb...@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<sberyozkin@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<sberyozkin@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<sberyozkin@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<ow...@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 [rmannibucau@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<sberyozkin@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.
>
>
RE: fediz & SSO?
Posted by Cabrera Juan Manuel <Ju...@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:owulff@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 [rmannibucau@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 <sb...@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<sberyozkin@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<sberyozkin@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<sberyozkin@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<ow...@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 [rmannibucau@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<sberyozkin@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.
RE: fediz & SSO?
Posted by Oliver Wulff <ow...@talend.com>.
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 [rmannibucau@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 <sb...@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<sberyozkin@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<sberyozkin@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<sberyozkin@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<ow...@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 [rmannibucau@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<sberyozkin@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
sounds closer to what i was expecting ;)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/21 Sergey Beryozkin <sb...@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<sberyozkin@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<sberyozkin@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<sberyozkin@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<ow...@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 [rmannibucau@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<sberyozkin@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
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>
Re: fediz & SSO?
Posted by Sergey Beryozkin <sb...@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*
>
>
>
>
> 2012/8/21 Sergey Beryozkin<sb...@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/**
>>> 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>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/21 Sergey Beryozkin<sberyozkin@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>>
>>>>> *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2012/8/21 Sergey Beryozkin<sberyozkin@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://**rmannibucau.wordpress.com<http://rmannibucau.wordpress.com>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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://**rmannibucau.wordpress.com<http://rmannibucau.wordpress.com>
>>>>>>>>>>
>>>>>>>> *
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> 2012/8/17 Sergey Beryozkin<sberyozkin@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://**rmannibucau.wordpress.com<http://rmannibucau.wordpress.com>
>>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>> *
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>>
>>>>>>>>> Sergey Beryozkin
>>>>>>>>>
>>>>>>>>> Talend Community Coders
>>>>>>>>> http://coders.talend.com/
>>>>>>>>>
>>>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>
>>>
>
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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*
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/21 Sergey Beryozkin <sb...@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/**
>> 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>
>> *
>>
>>
>>
>>
>> 2012/8/21 Sergey Beryozkin<sberyozkin@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>>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 2012/8/21 Sergey Beryozkin<sberyozkin@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://**rmannibucau.wordpress.com<http://rmannibucau.wordpress.com>
>>>>>> >>
>>>>>>
>>>>>>
>>>>>> *
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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://**rmannibucau.wordpress.com<http://rmannibucau.wordpress.com>
>>>>>>> >>
>>>>>>> *
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 2012/8/17 Sergey Beryozkin<sberyozkin@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://**rmannibucau.wordpress.com<http://rmannibucau.wordpress.com>
>>>>>>>> >>>
>>>>>>>>
>>>>>>>>
>>>>>>> *
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>> Sergey Beryozkin
>>>>>>>>
>>>>>>>> Talend Community Coders
>>>>>>>> http://coders.talend.com/
>>>>>>>>
>>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>
Re: fediz & SSO?
Posted by Sergey Beryozkin <sb...@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/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*
>
>
>
>
> 2012/8/21 Sergey Beryozkin<sb...@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>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/21 Sergey Beryozkin<sberyozkin@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://rmannibucau.wordpress.com>>
>>>>>
>>>>> *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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://rmannibucau.wordpress.com>>
>>>>>> *
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> 2012/8/17 Sergey Beryozkin<sberyozkin@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://rmannibucau.wordpress.com>>>
>>>>>>>
>>>>>>
>>>>>> *
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>> Sergey Beryozkin
>>>>>>>
>>>>>>> Talend Community Coders
>>>>>>> http://coders.talend.com/
>>>>>>>
>>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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/idp/src/main/java/org/apache/cxf/fediz/service/idp/IdpServlet.java
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/21 Sergey Beryozkin <sb...@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>
>> *
>>
>>
>>
>>
>> 2012/8/21 Sergey Beryozkin<sberyozkin@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://rmannibucau.wordpress.com>>
>>>>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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://rmannibucau.wordpress.com>>
>>>>> *
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> 2012/8/17 Sergey Beryozkin<sberyozkin@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://rmannibucau.wordpress.com>>>
>>>>>>
>>>>>
>>>>> *
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>> Sergey Beryozkin
>>>>>>
>>>>>> Talend Community Coders
>>>>>> http://coders.talend.com/
>>>>>>
>>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>
Re: fediz & SSO?
Posted by Sergey Beryozkin <sb...@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*
>
>
>
>
> 2012/8/21 Sergey Beryozkin<sb...@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>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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>
>>>> *
>>>>
>>>>
>>>>
>>>>
>>>> 2012/8/17 Sergey Beryozkin<sberyozkin@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>>
>>>>
>>>>> *
>>>>>>
>>>>>>
>>>>>>
>>>>> --
>>>>> Sergey Beryozkin
>>>>>
>>>>> Talend Community Coders
>>>>> http://coders.talend.com/
>>>>>
>>>>> Blog: http://sberyozkin.blogspot.com
>>>>>
>>>>>
>>>>
>>>
>
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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?)
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/21 Sergey Beryozkin <sb...@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>
>> *
>>
>>
>>
>>
>> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/17 Sergey Beryozkin<sberyozkin@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>>
>>>
>>>> *
>>>>>
>>>>>
>>>>>
>>>> --
>>>> Sergey Beryozkin
>>>>
>>>> Talend Community Coders
>>>> http://coders.talend.com/
>>>>
>>>> Blog: http://sberyozkin.blogspot.com
>>>>
>>>>
>>>
>>
Re: fediz & SSO?
Posted by Sergey Beryozkin <sb...@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*
>
>
>
>
> 2012/8/20 Oliver Wulff<ow...@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 [rmannibucau@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*
>>
>>
>>
>>
>> 2012/8/17 Sergey Beryozkin<sb...@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>
>>>> *
>>>>
>>>>
>>>
>>> --
>>> Sergey Beryozkin
>>>
>>> Talend Community Coders
>>> http://coders.talend.com/
>>>
>>> Blog: http://sberyozkin.blogspot.com
>>>
>>
>
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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).
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*
2012/8/20 Oliver Wulff <ow...@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 [rmannibucau@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*
>
>
>
>
> 2012/8/17 Sergey Beryozkin <sb...@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>
> >> *
> >>
> >>
> >
> > --
> > Sergey Beryozkin
> >
> > Talend Community Coders
> > http://coders.talend.com/
> >
> > Blog: http://sberyozkin.blogspot.com
> >
>
RE: fediz & SSO?
Posted by Oliver Wulff <ow...@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 [rmannibucau@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*
2012/8/17 Sergey Beryozkin <sb...@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>
>> *
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
Re: fediz & SSO?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
ok, great, so i'll wait some news from fediz ;)
thanks for the answer
*Romain Manni-Bucau*
*Twitter: @rmannibucau*
*Blog: http://rmannibucau.wordpress.com*
2012/8/17 Sergey Beryozkin <sb...@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>
>> *
>>
>>
>
> --
> Sergey Beryozkin
>
> Talend Community Coders
> http://coders.talend.com/
>
> Blog: http://sberyozkin.blogspot.com
>
Re: fediz & SSO?
Posted by Sergey Beryozkin <sb...@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*
>
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com