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 > "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: > >> 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 >> >> >> >> >> >> >> >> >> >> >> >
