cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cabrera Juan Manuel <Juan-Manuel.Cabr...@atos.net>
Subject RE: fediz & SSO?
Date Tue, 21 Aug 2012 14:59:07 GMT
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.


Mime
View raw message