You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by frank <fr...@gmail.com> on 2012/11/29 13:00:36 UTC
Inner workings of Fediz
Hi,
this week I've been toying around with the Fediz plugin and came across
behaviour that made me want to know more.
The situation is as follows:
- Fediz protects a resource on Tomcat and redirects the user's browser to
my Identity Provider. In this case I am using the Thinktecture
IdentityServer as an IDP.
- After login at the IDP, the browser receives a "postback form" containing
the token, and the browser automagically posts this form to Fediz. So far
so good.
- A session with my resource is established and everything works as should
be expected.
- When I have my resource invalidate the session (part of the logout proces
initiated by the user) and I browse back to my resource I am logged in
immedatiately, but with a different session (a new session cookie is used).
Obviously, my SAML token is still valid, but how did Fediz manage to rescue
that across two different sessions? How did Fediz determine that "I" am
still the same user trying to get access?
I didn't post the form, so Fediz somehow caches information that causes it
to assume this.
I would expect that Fediz, upon presentation of the token, would relate the
session (or session cookie) to the token and maintain state in that way.
However, the above suggests that things may work differently.
Does anyone know how this works under the hood?
Cheers,
Frank
Re: Inner workings of Fediz
Posted by frank <fr...@gmail.com>.
Hi,
As it turns out my IDP (Thinktecture Identity Server) has the same
behaviour.
Invalidating the session at the Fediz plugin side causes the plugin to
redirect the user's browser to the IDP. The IDP then simply reissues the
token, without prompting for credentials. The plugin then associates the
token with the new session and I'm back in.
>From a user perspective this is odd: once you're logged in, have a valid
token and have valid session with the IDP you are not prompted for
credentials when you trry to get in after a logout.
The technicalities are clear, but I am now working on implementing a call
to my IDP to make sure that along with invalidating the local session, the
IDP invalidates its session with the user's browser. I.e when the plugin
redirects to the IDP after this, the IDP will agwin prompt for credentials.
Cheers,
Frank
Hi,
>
> Fediz IDP maintains an own session for you. So when you invalidate the
> session at your RP the session at the IDP still is valid unless you delete
> the IDP session cookie.
>
> So long Fediz caches your SAML token until it either expires or you
> explicitly request a new one from STS (add "&wrefresh=0" to IDP request).
> But even then you will not be asked for your credentials until you restart
> your browser or remove the authentication headers from your requests to the
> IDP.
>
> Greetings,
> Peter
>
> Am 29.11.2012 13:00, schrieb frank:
>
>> Hi,
>>
>> this week I've been toying around with the Fediz plugin and came across
>> behaviour that made me want to know more.
>>
>> The situation is as follows:
>>
>> - Fediz protects a resource on Tomcat and redirects the user's browser to
>> my Identity Provider. In this case I am using the Thinktecture
>> IdentityServer as an IDP.
>> - After login at the IDP, the browser receives a "postback form"
>> containing
>> the token, and the browser automagically posts this form to Fediz. So far
>> so good.
>> - A session with my resource is established and everything works as should
>> be expected.
>> - When I have my resource invalidate the session (part of the logout
>> proces
>> initiated by the user) and I browse back to my resource I am logged in
>> immedatiately, but with a different session (a new session cookie is
>> used).
>>
>> Obviously, my SAML token is still valid, but how did Fediz manage to
>> rescue
>> that across two different sessions? How did Fediz determine that "I" am
>> still the same user trying to get access?
>>
>> I didn't post the form, so Fediz somehow caches information that causes it
>> to assume this.
>>
>> I would expect that Fediz, upon presentation of the token, would relate
>> the
>> session (or session cookie) to the token and maintain state in that way.
>> However, the above suggests that things may work differently.
>>
>> Does anyone know how this works under the hood?
>>
>> Cheers,
>>
>> Frank
>>
>>
>
RE: Inner workings of Fediz
Posted by Oliver Wulff <ow...@talend.com>.
I've refactored the IDP in trunk now which allows you to plug in another authenticator (instead of basic auth) into the processing chain or support another SSO protocol. All you have to do is write a new subclass of AbstractServletFilter to implement for instance a form based authentication (then you don't have to clean the active logins in the browser thus you really get re-authenticated).
Thanks
Oli
------
Oliver Wulff
Blog: http://owulff.blogspot.com
Solution Architect
http://coders.talend.com
Talend Application Integration Division http://www.talend.com
________________________________________
From: Peter Schyma [pschyma@adeece.com]
Sent: 29 November 2012 13:14
To: users@cxf.apache.org
Subject: Re: Inner workings of Fediz
Hi,
Fediz IDP maintains an own session for you. So when you invalidate the
session at your RP the session at the IDP still is valid unless you
delete the IDP session cookie.
So long Fediz caches your SAML token until it either expires or you
explicitly request a new one from STS (add "&wrefresh=0" to IDP
request). But even then you will not be asked for your credentials until
you restart your browser or remove the authentication headers from your
requests to the IDP.
Greetings,
Peter
Am 29.11.2012 13:00, schrieb frank:
> Hi,
>
> this week I've been toying around with the Fediz plugin and came across
> behaviour that made me want to know more.
>
> The situation is as follows:
>
> - Fediz protects a resource on Tomcat and redirects the user's browser to
> my Identity Provider. In this case I am using the Thinktecture
> IdentityServer as an IDP.
> - After login at the IDP, the browser receives a "postback form" containing
> the token, and the browser automagically posts this form to Fediz. So far
> so good.
> - A session with my resource is established and everything works as should
> be expected.
> - When I have my resource invalidate the session (part of the logout proces
> initiated by the user) and I browse back to my resource I am logged in
> immedatiately, but with a different session (a new session cookie is used).
>
> Obviously, my SAML token is still valid, but how did Fediz manage to rescue
> that across two different sessions? How did Fediz determine that "I" am
> still the same user trying to get access?
>
> I didn't post the form, so Fediz somehow caches information that causes it
> to assume this.
>
> I would expect that Fediz, upon presentation of the token, would relate the
> session (or session cookie) to the token and maintain state in that way.
> However, the above suggests that things may work differently.
>
> Does anyone know how this works under the hood?
>
> Cheers,
>
> Frank
>
Re: Inner workings of Fediz
Posted by Peter Schyma <ps...@adeece.com>.
Hi,
Fediz IDP maintains an own session for you. So when you invalidate the
session at your RP the session at the IDP still is valid unless you
delete the IDP session cookie.
So long Fediz caches your SAML token until it either expires or you
explicitly request a new one from STS (add "&wrefresh=0" to IDP
request). But even then you will not be asked for your credentials until
you restart your browser or remove the authentication headers from your
requests to the IDP.
Greetings,
Peter
Am 29.11.2012 13:00, schrieb frank:
> Hi,
>
> this week I've been toying around with the Fediz plugin and came across
> behaviour that made me want to know more.
>
> The situation is as follows:
>
> - Fediz protects a resource on Tomcat and redirects the user's browser to
> my Identity Provider. In this case I am using the Thinktecture
> IdentityServer as an IDP.
> - After login at the IDP, the browser receives a "postback form" containing
> the token, and the browser automagically posts this form to Fediz. So far
> so good.
> - A session with my resource is established and everything works as should
> be expected.
> - When I have my resource invalidate the session (part of the logout proces
> initiated by the user) and I browse back to my resource I am logged in
> immedatiately, but with a different session (a new session cookie is used).
>
> Obviously, my SAML token is still valid, but how did Fediz manage to rescue
> that across two different sessions? How did Fediz determine that "I" am
> still the same user trying to get access?
>
> I didn't post the form, so Fediz somehow caches information that causes it
> to assume this.
>
> I would expect that Fediz, upon presentation of the token, would relate the
> session (or session cookie) to the token and maintain state in that way.
> However, the above suggests that things may work differently.
>
> Does anyone know how this works under the hood?
>
> Cheers,
>
> Frank
>