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 [[email protected]] Sent: 29 November 2012 13:14 To: [email protected] 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 >
