geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Wilkins <gr...@mortbay.com>
Subject Re: Question about web app login, user principal, and authentication
Date Sun, 08 Jan 2006 11:02:00 GMT

David,

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!

cheers










Mime
View raw message