geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeppe Sommer <>
Subject Re: Question about web app login, user principal, and authentication
Date Sun, 08 Jan 2006 19:15:26 GMT
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):

"Being logged in to a web application corresponds precisely to there 
being a valid non-null value in getUserPrincipal method"

There is no mention that this should apply only to protected resources. 
So if the user is logged in, getUserPrincipal must return non-null.

Regarding your 3rd alternative (below): I don't see why you want to 
re-authenticate the user, including when calling getUserPrincipal during 
the request for at an unprotected resource. The realm has already 
accepted the credentials, so why check them again, with the risk of a 
performance degradation?

I guess my underlying assumption is that the webcontainer will track the 
login state/credentials in a session, as suggested by the servlet spec 
(also section 12.10).

Cheers, Jeppe

Greg Wilkins wrote:

>I do not believe that the servlet spec well defines the behaviour of the 
>getUserPrincipal() method for un-secured resources.
>I raised this with the EG during the 2.4 process and pointed out that
>several containers implemented this differently.   Specifically I wanted
>to know that if getUserPrincipal() is called for a un-securied resource
>would the return be:
>  1) Null
>  2) The principal associated with the request (by session or otherwise)
>     that was authenticated by a previous request, but not reauthenticated for this
>     request.  The actual authentication of the principal may have expired or
>     been revoked.
>  3) The principal associated with the request (by session or otherwise)
>     that is re-authenticated with the realm for this request.
>I don't believe anything in SRV 12 or the javadoc makes it clear which of these 
>is the correct choice (not even 12.7 as Jeppe suggests, as it is not defined 
>what the "security identity of a web user" is for a non secured resource.
>Note that as some authentication mechanism (eg BASIC) have paths associated 
>with them by the browser, it is possible to have different credentials for 
>different paths within the same web application.   For example, if a user
>first authenticates at /context/auth/something, then the browser will only
>present credentials for /context/auth/* and the user will not be known for
>/context/other/something or in fact, different credentials may be request
>and provided by the browser!    So for some mechanisms, there is not
>even a concept of context wide authentication.
>At the time I raised the issue with the EG I was not able to get a clear 
>resolution (wonders of the JCP).  I think I suggested having an explicit
>lazy authentication ie specify that a request should be authenticated
>with the realm IFF credentials are available in the session or request
>and additional user interaction is not required.    I'll have to dig
>up my mail archives to see the reasons against this.
>For now, I beleive that most containers implement lazy authentication
>for non-secured requests at the time that getUserPrincipal is called.
>So any credentials present in the session and/or request will be 
>rechecked with the realm.  Thus option 3) above is the defacto status.
>But what credentials are available depends greatly on the auth
>mechanism used.
>It also does mean that you must be careful with any filters or
>interceptors that call getUserPrincipal, as that call may have
>the side affect of triggering a possible expensive and remote
>call to an authentication mechanism.   Don't call it unless
>you really need it!

View raw message