And what about just storing an "I'm authenticated" flag in the session, associated with the username (which is already there...) ? This way I have no problems about password changes... Therefore, i think password is already stored clearly in the session object as the attribute "j_password", isn't it ?
-----Messaggio originale----- Da: Randy Layman [mailto:[EMAIL PROTECTED]] Inviato: martedì 2 ottobre 2001 14.34 A: [EMAIL PROTECTED] Oggetto: RE: Caching Login Info in Tomcat 3.2.x > -----Original Message----- > From: André de Jesus [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, October 02, 2001 9:03 AM > To: [EMAIL PROTECTED] > Subject: Re: Caching Login Info in Tomcat 3.2.x > > > > If you are using container-managed authentication (the system > that comes > with Tomcat, that is configured for each Realm in the file > server.xml), > then the user roles and passwords are already automatically > cached for > each session (the isUserInrole() function and other similar > functions do > not trigger database accesses every time). Actually that is not correct. The JdbcRealm class that is provided with Tomcat does do a database connection for each request. It never stores authentication information. The provided class could be modified to provide the caching requested, but you would have to recode the Realm (which isn't a big deal). There is only a security risk if you store passwords unencrypted in memory and someone has enough access to your system to perform a memory dump (and then the intelligence of look at the dump and find the Map, List, or array of authentication credentials). The biggest problem to watch out for is removing cached information - it a user changes their password and then exits the application (either explicitly or implicitly) then you need to make sure that their cached information is removed before they come back and try to use their new password. > > If, on the other hand, you are authenticating the users with you own > authentication system, then you could cache the authentication > information in a session object (this is exactly what Tomcat does by > default). Then, all private pages would check if the session object > exists and if the user has been authenticated before displaying the > private information. > > The only publicly visible key to this object is the session > id, so all > security problems could come from this session key being known to > intermediate parties. Depending from the security level > required by your > application, you could consider setting lower expiration > times for the > session (or even explicitly expiring the session once some user > operations have been successfully completed, with > setMaxInactiveInterval()), or protecting the http > communication with SSL. > > > Andre de Jesus > > > > > Renato Romano wrote: > > >Hi, > >I would like Tomcat avoiding to access the DB for EVERY > ACCESS to a reserved > >page. I think the best way to do this (apart from upgrading > to Tomcat 4.0 > >!!) is to store the login info, or maybe just a flag "I'm > authenticated", in > >the session object. Does anyone already made something > similar ? Should I > >only redefine methods in my Realm object ? Is there some > security issue I'm > >not taking care of ?? > >Thanks > > > >Renato > > > > -- > André de Jesus <[EMAIL PROTECTED]> > TEKTIX - Consultoria em Sistemas de Informação, L.da > http://www.tektix.com > > >
