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
