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
