Tomcat j_security_check skips authentication after timeout?

[rop <ro...@gmail.com>]

I got the responsibility of maintaining a legacy web-application running on
Tomcat 5.5.36 and using the *j_security_check* feature for
user-authentication.

One problem scenario I am looking into:

When you first start the browser and logon to the application, everything
works OK....

The application receives the username from *request.getRemoteUser()* and
looks up user-roles in config-tables, for exactly what each user is allowed
to do in the GUI.

*The problem is* when a user leaves the application inactive for an
extended time (not clear yet exactly how long, but more than an hour) and
then submits a form.

It now appears that tomcat may have discarded the authentication-info,
because of time-out I guess, and *request.getRemoteUser()* will return *null
*, which result in a broken GUI-display.

I would expect (prefer) Tomcat, in this case to request the
login-credentials anew, before accessing the application, but for some
reason it does not.

For info, the *web.xml* under *{TOMCAT_HOME}/config* has
 ...<session-timeout>240</session-timeout>...
while the *web.xml* in the application WAR-file has no session-timeout
specified at all.

What do I need to do to get Tomcat to always ask for login-credentials
again, when needed, and make sure *request.getRemoteUser()* is never null
when calling the application?

Anyone has a clue?

Re: Tomcat j_security_check skips authentication after timeout?

[Christopher Schultz <ch...@christopherschultz.net>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Rop,
On 12/21/12 4:01 PM, rop wrote:
> I got the responsibility of maintaining a legacy web-application
> running on Tomcat 5.5.36 and using the *j_security_check* feature
> for user-authentication.

Obligatory warning: Tomcat 5.5.x is no longer supported. You will
likely get better help, feedback, results, etc. by upgrading. Most web
applications can be migrated to later versions (Tomcat 7.0.x is
current) with little adjustment.

Moving on...

To be clear, you're talking about using FORM authentication, right?

> One problem scenario I am looking into:
> 
> When you first start the browser and logon to the application,
> everything works OK....
> 
> The application receives the username from
> *request.getRemoteUser()* and looks up user-roles in config-tables,
> for exactly what each user is allowed to do in the GUI.

Technically, Tomcat uses role-based authorization for URL-patterns.
Whatever you do in the GUI is up to you.

> *The problem is* when a user leaves the application inactive for
> an extended time (not clear yet exactly how long, but more than an
> hour) and then submits a form.

In this case, the HttpSession has expired and the user is no longer
authenticated.

> It now appears that tomcat may have discarded the
> authentication-info, because of time-out I guess, and
> *request.getRemoteUser()* will return *null *, which result in a
> broken GUI-display.

Since Tomcat does not control your UI, this is your application's fault.

> I would expect (prefer) Tomcat, in this case to request the 
> login-credentials anew, before accessing the application, but for
> some reason it does not.

If you have a <security-constraint> with an <auth-constraint> on the
URL(s) you are serving, then Tomcat *will* request the user's
credentials anew. I suspect you have a simple "login" screen that is
protected and nothing else is.

> For info, the *web.xml* under *{TOMCAT_HOME}/config* has 
> ...<session-timeout>240</session-timeout>...

That is likely a mistake on your (or someone else at your
organization's) part.

> while the *web.xml* in the application WAR-file has no
> session-timeout specified at all.

This is the proper place for a web application's session timeout to be
set.

> What do I need to do to get Tomcat to always ask for
> login-credentials again, when needed, and make sure
> *request.getRemoteUser()* is never null when calling the
> application?

Please post an example URL to your web application that results in a
"broken GUI" after the session times-out.

Also, post all <security-constraint> elements (and their children)
from your WEB-INF/web.xml file. Feel free to sanitize and/or anonymize
them as necessary (but consistently: if you say that you are
requesting /foo/bar and your constraint is on /bar/baz then we're
going to tell you that's the problem).

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEAREIAAYFAlDU474ACgkQ9CaO5/Lv0PBHTwCdF+G0v+l9+T1Ht2tjoe4RJiB1
1zgAni2Px6X/nddHKiDfKxEF8Il30Yg9
=Aykg
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org