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
