Although we are working in a Websphere/LDAP environment, we had the same requirement as you, and we managed to solve it.
What we did (and I'm going from fairly distant memories, so hopefully I'm at least close to right) is this... user logs on. We have a filter that checks for password expired/reset (both a forced PW change) via flags set in a previous filter (values taken from LDAP) and redirects to the change screen if applicable. This all of course happens only after a "successful" logon, i.e., user entered valid credentials, including expired password already. We destroy the session before leaving that filter. Password is changed, all without creating a new session along the way. Once it is changed, we redirect back through the logon process as before. We decided that it was *better* to make the user log on again because it proves they remember the password they entered 2 seconds ago :) I suppose if I had to allow that automatic authentication, I would NOT destroy the session and instead just redirect to the first protected resource of the app from the change PW screen. Since the user was let in the first time around, they are really authenticated already. In essence, the filter that catches that forced PW change flag is acting like the container, intercepting all protected requests and redirecting to a change PW screen. If you did it smartly you should be able to grab what resource was requested when the filter fired so as to not have to hardcode where to go to after that forced PW screen is finished. Frank -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] On Tue, October 11, 2005 12:24 pm, Peter Bright said: > >> -----Original Message----- >> From: Caldarale, Charles R [mailto:[EMAIL PROTECTED] >> Sent: 11 October 2005 17:23 >> To: Tomcat Users List >> Subject: RE: Form Based Authentication >> >> > From: Peter Bright [mailto:[EMAIL PROTECTED] >> > Subject: RE: Form Based Authentication >> > >> > > > >> > > > It's point (c) that's proving problematic; there's no way to >> > > > reauthenticate that I can see. >> > > >> > > What happens if you just invalidate the existing session? >> > >> > The user gets logged out. >> >> Exactly - and they then must reauthenticate with the updated password. >> Isn't that what you want? >> > No, sorry, it was unclear. I want them to be reauthenticat/ed/ with the > new credentials /automatically/. Without making them have to > reauthenticate /by hand/. > > ******************************************************************************* > The information contained in this electronic message may be confidential > and/or privileged. Any unauthorized use, dissemination, distribution, or > reproduction is strictly prohibited. If you have received this > communication in error, please contact the sender by reply email and > destroy all copies of the original message. > ******************************************************************************* > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
