Tomcat server timeout settings not working as expected.

Tim Holloway wrote:There most definitely is a system used for A/A. ALWAYS. I repeat. It's not magic and it's not automatic.

When we started, you said "Tomcat server timeout", which to me implied that you were using the JEE standard Container-Manager Security system that's built into Tomcat. That system has Tomcat (the container) managing authentication and authorization. The container security system looks at the webapp's /WEB-INF/web.xml file (or annotation equivalents to determine transport security, security roles and their mapping to URLs as well as whether to use FORM-based or BASIC security for the login process.

In container-managed security, the webapp has no login code of its own. Instead, when a protected URL is submitted to Tomcat, Tomcat parks the URL request and runs its own login code internally. Until/unless the user presents valid login credentials, the process does not enter application code. Once authenticated, the original URL requeust proceeds to the webapp.

Tomcat handles authentication using Realms, which are plug-in modules that support authentication methods via a standard Realm Interface. The authentication methods simply take in the credentials and return a pass/fail to Tomcat's login logic. The Realms themselves may authenticate against databases, LDAP/Active Directory servers, XML files (reccommended only for testing) or any other soure you can think of. If none of the standard set works, you can implement your own Realm (been there/did that).

Container Security can also jack into meta-security (Simgle Sign-on) systems such as Kerberos or Windows Security. In which case, the Tomcat server may not need a signon because SSO allows the user to come in pre-authenticated. Which is why there is no "login" event defined for JEE webapp containers.

And that's just assuming that you ARE using JEE standard Authentication. It's very important to know how you're authenticating, because while HttpSessions support container security, they are not only applicable to container security. Thus a timeout of the session may not always be equivalent to logging out.

I am not really sure what you mean here. To the best of my knowledge and understanding, Tomcat forwards each request to the respective handler. A/A is left to those respective apps to handle? It is those apps that are responsible to return the relevant HTTP error codes. Am I wrong with my understanding. Always looking to learn, so kindly feel at ease to correct me if I am mistaken... :-)

You are mistaken.

There are 2 ways to handle A&A. One is for the application itself to totally handle security. This is the dangerous way. The other is to let the container handle security. This is the safer way.

The JEE standard defines the Container-Based Security System - a set of container implementation specs and API methods that allow an incoming URL to be checked BEFORE it is dispatched to the webapp, to ensure the authenticity of the requester and to forbid access to URLs for which the requester does not possess a valid security role. In other words, there is no login code in the web application itself, it's all in the server (Tomcat, WebSphere, Wildfly or whatever) and forbidden requests never reach the webapp at all. Which means that they cannot reach possibly weak spots to exploit.

Yhe container security system is configured by elements in the webapp's /WEB-INF/web.xml file or annotation equivalents and from the servlet deployment Context, but none of the primary security for the application are in application code. You can fine-tune security using certain API methods such as the HttpServletRequest isUserInRole() method, and you can get the login userId from the getRemoteUser() method, but the primary wall against unauthorized access is completely automatic and done entirely outside of the webapp by Tomcat itself.

So to make that work, you not only have to configure security elements in web.xml, you also have to define a security Realm for the webapp when it is deployed.

Technically speaking, there are two components used to deploy any JEE webapp. There's the server-independent deployment Descriptoi, whic is the web.xml file (again, or annotation equivalents). And there's the server-dependent Deployment Descriptor. The name and media/format of the server-dependent deployment descriptor is uniiquely defined by and for the implmenters of the webapp container, For Tomcat, it's the Context XML which can be located in the WAR's META-INF diretory or in the TOMCAT_HOME/conf/Catalina/localhost directory or one of several other places detailed in the Tomcat documentation.. It is this Context, or in inherited super-context from the TOMCAT_HOME/coonf/server.xml file that determines where and how to validate userid, password and security roles.

By default, no primary or inherited security context (Realm) is configured for Tomcat webapps. Normally you would do this in the Context, just as you would the Database Connection Pool specs.

So our question is, are you using that system, and if so, what kind of Realm do you have configured for it?

Trying to digest all of what you said!

Had come across this Tomcat JIRA -
https://bz.apache.org/bugzilla/show_bug.cgi?id=67793

Seems this issue occurs with multiple versions.
I upgraded to 9.0.83 and that seems to have resolved the issue.

Oops allow me to eat my own words.

My testing efforts reveal that SSO enabled customers will still face the same issue (session timeout within a minute).
I am not sure I understand why Tomcat would treat SSO users any different! (Maybe my understanding of HOW SSO is implemented is wrong).

My approach goes like this -
No customers faced this issue till now. Now after a couple of new releases there's a ton of them complaining.
So I look at what has changed.
I don't see no code changes, this area is critical and has not been 'touched' in ages.

Drill down deeper I see there has been a couple of Tomcat version upgrades.
How would that matter? Well, the implementation of timeout interval has to be on the Server?

I upgrade to 9.0.83 but then again looks like the issue is nowhere near solved completely.
Now I am left clueless.
Gentlemen, any suggestion will be appreciated.

The timeout period for SSO should be managed by the SSO security manager itself, since the whole point of SSO is that you can be logged into and using multiple apps at once.

However, that's different than Session timeout. Session timeout is the interval before the user's HTTPSession object gets discarded and only secondarily about being logged in. So in theory at least, you could still be "logged in" (to SSO), but after too long a period of webapp inactivity, your session state could be lost, leaving you basically back where you were when you first logged in, despite having never formally logged out. And ONLT the webapp "work time" counts towards resetting session timeout. If you have SSO managing a Tomcat app and a database editing app and spent the last hour only talking to the database editor, Tomcat will have timed out its HTTPSession.