Hi, I'm not participating for your email group regularly. But this email attracted my attention. In this case if I had understood your email message, your group sees the fact that admins can change users without invalidating the session as an advantage. However in most of the applications I have seen in the industry, people cache certain user specific objects in the session. (say a User object for example). In J2EE, we don't have an Event listener forn observing a change of remote user (Only Session listeners and attribute listeners). Therefore the programmer will have to compare the remote user and the objects cached in the session in every request to ensure that the cached objects belong to the new user. In this case we break the idea that container takes care of sessions validity (based on cookie or url- rewriting). If people have already written applications based on the Spec, they will find portability issues with your app server.
regards!!! Dulshan De Silva Applications Engineer A*R*C Tel. (813) 371-7525; Fax (813) 612-3001 e-mail: [EMAIL PROTECTED] URL: http://www.arccorp.com -----Original Message----- From: Greg Wilkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 9:20 AM To: [EMAIL PROTECTED] Subject: Re: Question about web app login, user principal, and authentication Jeppe Sommer (Trifork) wrote: > Greg, > > I agree that there is an amount of implementation freedom wrt. when > getUserPrincipal can be expected to return non-null depending on the > caching strategy of the container, at least when using basic login. > However, with form based login (which, in my experience, is by far the > most commonly used J2EE username/password authentification mechanism), > it is reasonable to assume that the user principal is cached in session > state. For the record, the Trifork server caches user credentials with > both basic and form based login. I agree this is a safe assumption for FORM authentication > And although it is a valid implementation choice to reauthenticate > repeatedly, I don't think that it is commonly expected that a user is > immediatly kicked out of live login sessions if the sysadm changes the > password (talking IT systems in general). True. But it is also reasonable to expect that if credit expires, that a user cannot keep using a service because their session has not expired. Likewise, system admins should be able to change user roles and have those changes take affect without needing the user to restart their session. The password change issue is made worse by the fact that there is no way to progromatically (re)authenticate, so a change password page cannot reauthenticate for the user. Now I'm not arguing that this is all good or anything, I'm just pointing out that the spec does not tell us what to do here. Anything that uses a principal returned for a unprotected URL for authorization is going to be vulnerable to different interpretations of the specification. getUserPrincipal may return you a principal for non-protected resources, but in many cases it will not, even when the user has previously authenticated. Even when it does return a principal, there is no guarantee that it has the same standard of authentication as would a principal returned from a protected resource. cheers
