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<sberyoz...@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<sberyoz...@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<sberyoz...@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<owu...@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 [rmannibu...@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<sberyoz...@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
