Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <43C433F1.5080703@trifork.com>
Date: Tue, 10 Jan 2006 23:23:45 +0100
From: Jeppe Sommer <jso@trifork.com>
User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103)
MIME-Version: 1.0
To: dev@geronimo.apache.org
CC: ddesilva@ARCCorp.com
Subject: Re: Question about web app login, user principal, and authentication
References: <5D8D01A77142B5469E386C8894D67DD75C8414@arccorp.com>
In-Reply-To: <5D8D01A77142B5469E386C8894D67DD75C8414@arccorp.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Well, we don't store credentials in the session because we want to 
protect users from moody sysadms. We do it as an optimization (and to 
make form based login work in the first place). And it is not a spec 
violation - the spec explicitly suggests this strategy (but doesn't 
mandate it, as Greg has pointed out).

Cheers

Dulshan De Silva wrote:

>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: ddesilva@arccorp.com
>
>URL: http://www.arccorp.com 
>
>
>-----Original Message-----
>From: Greg Wilkins [mailto:gregw@mortbay.com] 
>Sent: Tuesday, January 10, 2006 9:20 AM
>To: geronimo-dev@apache.org
>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
>
>
>
>  
>