Rajkamal Pillai

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.

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.

Trying to digest all of what you said!

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... :-)

What I am trying to ask here if with or without SSO, each container manages their own individual User sessions?
To the best of my understanding, SSO would mean separate server(s) sharing Auth info amongst them.
That would definitely be A/A.

Am I correct in my understanding?

I still have a question here.
Even if SSO is enabled, it timeout would still be managed by the container?
So all that I mentioned above would still hold true?

Kindly do advice me on something.
Even if SSO is enabled Tomcat's web.xml settings and also the session.setMaxInactiveInterval() should work?
Wonder if I am looking up the wrong tree here?

Yes you just said the exact scenario. This issue happens with SSO enabled.
I thought SSO is something configured at the container (Tomcat) level, to basically share session information between independent servers.
Am I be wrong there?

Thanks a ton , Tim. I was not aware of half the things you mentioned.
Though I do know that the container looks at web.xml and configures itself or that is what I thought.

Tim,

As far as I understand there is no 'system' used for A/A.
I am just a Java app using Auth (and Authorization) levels as can be managed by a regular JEE app.
Like I had said earlier on one of my messages -
User logs in - he gets his permissions loaded - Including his session interval - and setMaxInactiveInterval() included.
That is pretty much about it.

To bring my question back into the discussion, I do not see the dynamic timeout setting (going by the setMaxInactiveInterval()) working. There also seems to be some JIRA there. Now is there any roundabout way in which I can deal with this scenario? A tomcat version upgrade appears to be an easy way out but kindly consider all the humongous effort that it would bring along? Another issue is I do not know which one to move to! A downgrade would be disastrous, is my gut feel.

Rajkamal Pillai wrote:
I'm not really sure what kinds of performance/usabilities issues you might be thinking of.  Can you give some examples?

Let's say I am really concerned about the security level(s) my application provides. In today's world where multiple people are working from the same workstation and my application don't timeout, there I have all hell break loose. Maybe my concern is a bit hypothetical but given that I am a product, I  cannott afford to ignore complaining customers.

Another aspect I am concerned about is, let's say I override sessionDestroyed(). So there will be like a database access more or less intermittently. Kindly see the scale I am dealing with. It is like tens of thousands of nodes and point products (if not more). I will have everybody screaming with my change. Even those ones for whom the timeout interval never really mattered.

In any case I opine that I am just an application hosted on a server (Tomcat here). That itself is a limitation. Unable to even come up with a workaround.

Rajkamal Pillai wrote:
I mean the User logs in - he/she (scared about the pronouns, here) gets validated against a database, the "User" object gets loaded - their timeout settings get loaded - setMaxInactiveInterval() is invoked - and they got about doing whatever business they care for. I might have an admin level user but I think that is irrelevant at this point.

There is also a Settings page where this interval can be modified. And there also setMaxInactiveInterval() is invoked.

I think not many Users bother to change this, so it stays at the default 30 minutes (according to web.xml). All of a sudden there are like a few Customers complaining. There has not been any Tomcat upgrade, as far as I am aware of. But I will re-verify this. Also please have a look at the Tomcat JIRA link I had posted earlier.

Tim,

To the best of my understanding I am not on any "login system". This is all OnPrem and there is no Spring Boot involved ("I" am a decade old, if not more).
When I say User object, I mean it is all done in-house, so to speak.
I mean the User logs in - he/she (scared about the pronouns, here) gets validated against a database, the "User" object gets loaded - their timeout settings get loaded - setMaxInactiveInterval() is invoked - and they got about doing whatever business they care for. I might have an admin level user but I think that is irrelevant at this point.

Did I answer your query, Tim?

Note: Just to bring matters into perspective, I have multiple client "products" reaching out for the same. To check policies and such. And I am guessing they would be getting validated as well though to the best of my understanding all that is certificate based. Nevertheless, I think the same timeout should apply there as well?

Why do I get this feeling that I am missing something (or rather a ton of things) here, dunno!

Paul Clapham wrote: It seems like you don't need to extend the timeout interval for everybody, only for some people. If that's not the case and everybody should have an equally extended timeout interval, then just configure that interval into the server.

Yes, This is precisely what I am attempting to achieve. Hence the requirement that I set the timeout interval dynamically for each User.

Paul Clapham wrote: Otherwise, you're going to need a User object to assign a specified timeout interval for each person who has their timeout interval extended. You'd assign this interval when they sign in and there's no need to do it at any other time. Neither do you need a notification when the server times out. So this requires one message from client to server when the user signs in, without any requirement for the user to do anything. So there's no "usability side effect". If this counts as a "performance side-effect" then you need to go to the person saying that and suggest they start being realistic.

Yes Paul, I am fetching the timeout interval when each User logs in and executing session.setMaxInactiveInte4rval(xxx). This is what is not being honored by Tomcat. Also I have a Settings page where this interval can be modified. I execute session.setMaxInactiveInte4rval(xxx) in that flow, as well, but again the interval defaults back to 30 seconds.

Paul Clapham wrote:  Perhaps I've missed some of your requirements. I'm assuming you don't want security side-effects like allowing the user to leave the session signed in for a long period of time while they are absent from the computer.

There you are! This is one of my major worries. Work with a product so I assume you would know how difficult it can get to opt for an upgrade any of the dependencies. But right now, there are a few customers complaining about this so I just might be able to convince them to. Even if I were to go that route, I am not certain about which version of Tomcat would resolve this.

Thanks a Ton!
:beerchug:

Paul Clapham wrote:

Rajkamal Pillai wrote:According to my understanding Tomcat checks for session timeouts in intervals. Then the server should timeout around the set interval (web.xml). Or does Tomcat check for this timeout interval when it receives each new request?

I don't know how Tomcat does that but... if I were designing a system like this, I wouldn't be checking sessions every X minutes to see if they had expired. I would just check a session when a related request came in, and expire the session if it had timed out then. But that's just me. Perhaps you could mention where your understanding came from?

https://tomcat.apache.org/tomcat-4.0-doc/config/manager.html
Kindly search for "checkInterval".

Ron,

I am on Tomcat 9.0.76
Can you kindly advice what version I should look to upgrade to?