cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
Subject Re: fediz & SSO?
Date Wed, 22 Aug 2012 08:00:54 GMT
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