cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: fediz & SSO?
Date Wed, 22 Aug 2012 09:15:01 GMT
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 <coheigea@apache.org>

> What kind of integration do you propose?
>
> Colm.
>
> On Wed, Aug 22, 2012 at 8:14 AM, Romain Manni-Bucau
> <rmannibucau@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 <Juan-Manuel.Cabrera@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 <sberyozkin@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<owulff@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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message