geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeppe Sommer (Trifork)" <...@trifork.com>
Subject Re: Question about web app login, user principal, and authentication
Date Mon, 09 Jan 2006 08:35:17 GMT
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.

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).

Cheers, Jeppe

Greg Wilkins wrote:

>Jeppe Sommer wrote:
>  
>
>>I think that it is possible to read from the servlet spec that
>>getUserPrincipal should return the current principal for an unprotected
>>resource. Take the following quote (servlet 2.4, section 12.10):
>>    
>>
>
>Jeppe,
>
>The problem is that "current" is just not defined and it is totally
>implementation dependant. For FORM authentication, the current user is 
>defined by the session.  For BASIC authentication, the current user is
>defined by the browser invocation and and path.  For CERT the current 
>user is defined by connection and authentication credentials can be 
>available before a protected resource has been accessed.
>
>To answer the original question - getUserPrincipal MAY return 
>a principal for unprotected resource, but it is undefined when
>that is.
>
>So any application that expects unprotected resources to have a 
>non-null principal is going to have problems if the authentication
>mechanism is changed.   The boundaries simply cannot be defined
>as "user previously accessed a protected resource".
>
>
>If the credentials are available in the request, session or connection, 
>then they really should be checked before a principal is returned.    
>The reason for this is that credit expires, permissions are
>revoked and bad users can have their accounts cancelled. Also it is
>possible that the credentials are present, but have never been checked
>within the current "session".
>
>So credentials must be (re)checked at some point, again the spec does not 
>tell us when and the natural boundaries are very much implementation 
>dependant (request, connection, session, etc.).  Thus Jetty checks the 
>credentials whenever a request passes a declaritive authentication point 
>or whenever a programatic authentication API is called.
>
>cheers
>
>
>  
>

Mime
View raw message