geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Aaron Mulder <ammul...@alumni.princeton.edu>
Subject Re: Question about web app login, user principal, and authentication
Date Sun, 08 Jan 2006 15:54:51 GMT
My preferred behavior would be to return the login Principal of the
user even for unauthenticated pages (unless they've logged out or
timed out, of course).  As a side effect, I think this would let us
drop the required defualt principal from the security mapping, which
would be great.  Unfortunately, I can't justify this by spec
references.  :)

Thanks,
    Aaron

On 1/8/06, Greg Wilkins <gregw@mortbay.com> wrote:
>
> 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