subject:"Re\: fediz \& SSO\?"

Re: fediz & SSO?

2012-08-22 Thread Romain Manni-Bucau

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 

> What kind of integration do you propose?
>
> Colm.
>
> On Wed, Aug 22, 2012 at 8:14 AM, Romain Manni-Bucau
> 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 
> >
> > > 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:owu...@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 [rmannibu...@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 
> > >
> > > > 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 s

Re: fediz & SSO?

2012-08-22 Thread Colm O hEigeartaigh

What kind of integration do you propose?

Colm.

On Wed, Aug 22, 2012 at 8:14 AM, Romain Manni-Bucau
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 
>
> > 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:owu...@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 [rmannibu...@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 
> >
> > > 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
> > >>
> > >>  On 21/08/12 11:53, Romain Manni-Bucau wrote:
> > >>>
> > >>>  from what i saw (IdpServlet) it doesn't keep it an

Re: fediz & SSO?

2012-08-22 Thread Romain Manni-Bucau

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 

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

RE: fediz & SSO?

2012-08-21 Thread Cabrera Juan Manuel

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

> 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
>>
>>  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 mul

RE: fediz & SSO?

2012-08-21 Thread Oliver Wulff

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

> 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
>>
>>  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
>>>>
>>>>   Hi
>>>>
>>>>>
>>>>> On 21/08/12 11:42, Romain Manni-Bucau wrote:
>>>>>
>>>>>   well i thought of some dis

Re: fediz & SSO?

2012-08-21 Thread 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
>>>>>>
>>>>>>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
>>>>>>>>
>>>>>>>> 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
>>>>>>>>>
>&g

Re: fediz & SSO?

2012-08-21 Thread Sergey Beryozkin

7;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

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?

2012-08-21 Thread Romain Manni-Bucau

l 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
>>>>>>
>>>>>>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
>>>>>>>
>>>>>>>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?

2012-08-21 Thread Sergey Beryozkin


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


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

  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

   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>>
*





2012/8/17 Sergey Beryozkin

   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

Re: fediz & SSO?

2012-08-21 Thread Romain Manni-Bucau

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 

> 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
>>
>>  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
>>>>
>>>>   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 <ht

Re: fediz & SSO?

2012-08-21 Thread Sergey Beryozkin


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


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

  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>
*




2012/8/17 Sergey Beryozkin

  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?

2012-08-21 Thread Romain Manni-Bucau

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 

> 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
>>
>>  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>
>>> *
>>>
>>>
>>>
>>>
>>> 2012/8/17 Sergey Beryozkin
>>>
>>>  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?

2012-08-21 Thread Sergey Beryozkin


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


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*




2012/8/17 Sergey Beryozkin


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?

2012-08-20 Thread Romain Manni-Bucau

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 

> 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*
>
>
>
>
> 2012/8/17 Sergey Beryozkin 
>
> > 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?

2012-08-20 Thread Oliver Wulff

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*




2012/8/17 Sergey Beryozkin 

> 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?

2012-08-17 Thread Romain Manni-Bucau

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 

> 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
>

Re: fediz & SSO?

2012-08-17 Thread Sergey Beryozkin


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

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

RE: fediz & SSO?

RE: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

RE: fediz & SSO?

Re: fediz & SSO?

Re: fediz & SSO?

17 matches

Site Navigation

Mail list logo

Footer information