Re: Question about web app login, user principal, and authentication
The servlet 2.4 spec, section 12.7 states: "A security identity, or principal, must always be provided for use in a call to an enterprise bean. The default mode in calls to enterprise beans from web applications is for the security identity of a web user to be propagated to the EJBTM container. In other scenarios, web containers are required to allow web users that are not known to the web container or to the EJBTM container to make calls: " ...then the spec goes on, describing scenarios where the user is not known to the web container - but this is not the case here, since the scenario is that the user is logged in. That is, if you are logged in (= the user is known), the web container must use your login principal in calls to the ejb container. Whether the current request is visiting a protected or unprotected resource is irrelevant. /Jeppe David Jencks wrote: i've been getting very confused by some behavior related to being logged in and authentication while working with jetspeed, and I hope someone can shed some light on what should be happening. Lets suppose you have a web app with some secured resources and some unsecured resources. If you start by accessing the unsecured resources, there is no doubt, you have not authenticated, getUserPrincipal() returns null, and you would get the DefaultSubject from ContextManager. Now if you access a secured resource, you log in, getUserPrincipal() returns a non-null principal, and you get the actual Subject from ContextManager during the call to the secured resource. Now if you go back and access an unsecured resource while still logged in, the servlet spec says you should still get the logged-in getUserPrincipal value, but ContextManager returns the DefaultSubject. So in particular calls to say an ejb will be based on the defaultSubject, not the logged in Subject, even though you are logged in. Is this correct? Or, should any access to a resource while logged in result in the ContextManager being set to the logged in subject? Spec references would be very welcome :-) thanks david jencks
Re: Question about web app login, user principal, and authentication
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
Re: Question about web app login, user principal, and authentication
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 <[EMAIL PROTECTED]> 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 > > > > > > > > > >
Re: Question about web app login, user principal, and authentication
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: 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
Re: Question about web app login, user principal, and authentication
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
Re: Question about web app login, user principal, and authentication
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
Re: Question about web app login, user principal, and authentication
I would tend to agree with Jeppe here. Thanks, Aaron On 1/9/06, Jeppe Sommer (Trifork) <[EMAIL PROTECTED]> wrote: > 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 > > > > > > > > >
Re: Question about web app login, user principal, and authentication
Jeppe Sommer (Trifork) wrote: > 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. I agree this is a safe assumption for FORM authentication > 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). True. But it is also reasonable to expect that if credit expires, that a user cannot keep using a service because their session has not expired. Likewise, system admins should be able to change user roles and have those changes take affect without needing the user to restart their session. The password change issue is made worse by the fact that there is no way to progromatically (re)authenticate, so a change password page cannot reauthenticate for the user. Now I'm not arguing that this is all good or anything, I'm just pointing out that the spec does not tell us what to do here. Anything that uses a principal returned for a unprotected URL for authorization is going to be vulnerable to different interpretations of the specification. getUserPrincipal may return you a principal for non-protected resources, but in many cases it will not, even when the user has previously authenticated. Even when it does return a principal, there is no guarantee that it has the same standard of authentication as would a principal returned from a protected resource. cheers
RE: Question about web app login, user principal, and authentication
Hi, I'm not participating for your email group regularly. But this email attracted my attention. In this case if I had understood your email message, your group sees the fact that admins can change users without invalidating the session as an advantage. However in most of the applications I have seen in the industry, people cache certain user specific objects in the session. (say a User object for example). In J2EE, we don't have an Event listener forn observing a change of remote user (Only Session listeners and attribute listeners). Therefore the programmer will have to compare the remote user and the objects cached in the session in every request to ensure that the cached objects belong to the new user. In this case we break the idea that container takes care of sessions validity (based on cookie or url- rewriting). If people have already written applications based on the Spec, they will find portability issues with your app server. regards!!! Dulshan De Silva Applications Engineer A*R*C Tel. (813) 371-7525; Fax (813) 612-3001 e-mail: [EMAIL PROTECTED] URL: http://www.arccorp.com -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 9:20 AM To: [EMAIL PROTECTED] Subject: Re: Question about web app login, user principal, and authentication Jeppe Sommer (Trifork) wrote: > 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. I agree this is a safe assumption for FORM authentication > 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). True. But it is also reasonable to expect that if credit expires, that a user cannot keep using a service because their session has not expired. Likewise, system admins should be able to change user roles and have those changes take affect without needing the user to restart their session. The password change issue is made worse by the fact that there is no way to progromatically (re)authenticate, so a change password page cannot reauthenticate for the user. Now I'm not arguing that this is all good or anything, I'm just pointing out that the spec does not tell us what to do here. Anything that uses a principal returned for a unprotected URL for authorization is going to be vulnerable to different interpretations of the specification. getUserPrincipal may return you a principal for non-protected resources, but in many cases it will not, even when the user has previously authenticated. Even when it does return a principal, there is no guarantee that it has the same standard of authentication as would a principal returned from a protected resource. cheers
Re: Question about web app login, user principal, and authentication
Well, we don't store credentials in the session because we want to protect users from moody sysadms. We do it as an optimization (and to make form based login work in the first place). And it is not a spec violation - the spec explicitly suggests this strategy (but doesn't mandate it, as Greg has pointed out). Cheers Dulshan De Silva wrote: Hi, I'm not participating for your email group regularly. But this email attracted my attention. In this case if I had understood your email message, your group sees the fact that admins can change users without invalidating the session as an advantage. However in most of the applications I have seen in the industry, people cache certain user specific objects in the session. (say a User object for example). In J2EE, we don't have an Event listener forn observing a change of remote user (Only Session listeners and attribute listeners). Therefore the programmer will have to compare the remote user and the objects cached in the session in every request to ensure that the cached objects belong to the new user. In this case we break the idea that container takes care of sessions validity (based on cookie or url- rewriting). If people have already written applications based on the Spec, they will find portability issues with your app server. regards!!! Dulshan De Silva Applications Engineer A*R*C Tel. (813) 371-7525; Fax (813) 612-3001 e-mail: [EMAIL PROTECTED] URL: http://www.arccorp.com -Original Message- From: Greg Wilkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 10, 2006 9:20 AM To: [EMAIL PROTECTED] Subject: Re: Question about web app login, user principal, and authentication Jeppe Sommer (Trifork) wrote: 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. I agree this is a safe assumption for FORM authentication 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). True. But it is also reasonable to expect that if credit expires, that a user cannot keep using a service because their session has not expired. Likewise, system admins should be able to change user roles and have those changes take affect without needing the user to restart their session. The password change issue is made worse by the fact that there is no way to progromatically (re)authenticate, so a change password page cannot reauthenticate for the user. Now I'm not arguing that this is all good or anything, I'm just pointing out that the spec does not tell us what to do here. Anything that uses a principal returned for a unprotected URL for authorization is going to be vulnerable to different interpretations of the specification. getUserPrincipal may return you a principal for non-protected resources, but in many cases it will not, even when the user has previously authenticated. Even when it does return a principal, there is no guarantee that it has the same standard of authentication as would a principal returned from a protected resource. cheers
