Tomcat server timeout settings not working as expected.

[Rajkamal Pillai]

Hello,

My default session timeout value is set to 30 in web.xml, so -
<session-timeout>30</session-timeout>
I understand that this is applicable across all user sessions.

Attempting to use -

session.setMaxInactiveInterval(300)

to change this at a User level to 5 mins.
(I am aware of the deprecation and shall be moving this to context).

The issue I face is that the value set through

setMaxInactiveInterval()

does not have appear to have much effect.
Remember reading that the timeout value will be defaulted to the value in web.xml (by a Tomcat process?).

Am I correct and is there any way around this?

[Tim Holloway]

As a rule, I don't recommend making the session timeout interval variable or per-user as it can be confusing to the user.

However, I cannot find any indication of deprecation of the setMaxInactiveInterval HttpSession method.

Two things to note, however.

1. Unlike the web.xml session timeout, setMaxInactiveInterval timeout interval is set in seconds, not minutes.

2. Session timeout is based on the interval between two client URL requests. If a request comes in after an interval exceeding the session timeout , the server (Tomcat or any other JEE server) will destroy the HttpSession object before beginning to process the URL request - assuming that no internal session cleanup hasn't done it first. That means that not only will the HttpSession object and its session-scope objects be destroyed, but container managed security will also be logged out, since JEE standard container security anchors itself to the user's HttpSession.

2a. Session timeout is based on the time between ANY two client URL requests. If you're displaying a web page with real-time updates from the server such as a stock tiker page and it's using AJAX or automatic page refresh, the AJAX or page refresh request are also URL requests as far as session timeout is concerned, and thus potentially the user may never timeout at all.

[Rajkamal Pillai]

Hello Tim,

Thanks for your response.
On checking localhost_access_log, I do not find any requests hitting Tomcat server. But for some reason the timeouts just do not work.
I am left without any idea where/what to look for now.

Best regards,
Rajkamal Pillai.

[Paul Clapham]

Is your problem that users are logged out based on the default rather than the override, or that they aren't logged out at all if there's an override, or something else?

[Tim Holloway]

Session timeout is not an application event and you should not expect to see session timeout in the logs unless you've got Tomcat's own internal logging cranked up. The only evidence you're going to see that a session timed out is when you make a request and the session isn't found anymore.

Recall that HTTP is not a constant-connection protocol the way something like an SSH session is where once the timeout has expired the server breaks the connection to the client. In HTTP, the connections only live as long as a single request/response cycle is executing, The session has no connection, it's only a repository for user-specific data.

[Rajkamal Pillai]

The issue I face is that the User is not logged off after the timeout duration. I mentioned the access log to highlight that there are no requests hitting the server during the 'inactive' period.

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?

[Tim Holloway]

How do you determine that the user has logged out? There are no login/logout events in JEE.

[Paul Clapham]

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?

[Ron McLeod]

Rajkamal Pillai wrote:The issue I face is that the User is not logged off after the timeout duration.

You should be able to get notifications of expiring sessions by registering a HttpSessionListener.  It will be called just after a session has been created (sessionCreated()), and just before a session is to be invalidated (sessionDestroyed()).

[Tim Holloway]

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?

I haven't checked, but I guess if Tomcat doesn't check sessions periodically, they'll hang around forever slowly filling up RAM.

Ron's suggestion is reasonable. It's not a "logout" as such, but since the standard logout process invalidates the session, you'd get that as a side effect.

[Rajkamal Pillai]

Tim Holloway wrote:How do you determine that the user has logged out? There are no login/logout events in JEE.

Well I am working with a web application. SO once the session has been invalidated the user would be redirected to the login screen?

[Rajkamal Pillai]

Paul Clapham wrote:
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?

I have been checking all over for a reasonable solution and that includes me going over Tomcat documentation as well as other blogs and articles. My information should be based on one of them. Apologies, I do not recollect where exactly  I gathered this piece of information from. Nevertheless what you say makes a lot of sense, especially from a performance standpoint.

[Rajkamal Pillai]

Ron McLeod wrote:

Rajkamal Pillai wrote:The issue I face is that the User is not logged off after the timeout duration.

You should be able to get notifications of expiring sessions by registering a HttpSessionListener.  It will be called just after a session has been created (sessionCreated()), and just before a session is to be invalidated (sessionDestroyed()).

I have a concern here. If I went the HttpSessionListener route I would be limited to a global scope, so to speak?
I did find some info on implementing a filter but then again I would be incurring a lot of performance complaints from thereon. Am I correct here?
I have another major concern here. Now if this is going on a global scope my concern is that as per my documentation we do provide the feature to limit the timeout duration per user.

[Rajkamal Pillai]

I also read this on Tomcat JIRA.
Tomcat JIRA

I did find another one that seemed more relevant but I am unable to find that now.

[Tim Holloway]

If it's a JIRA issue, then upgrading to a repaired version of Tomcat will help.

A SessionListener is for the HttpSesssion of an individular user. It's an application-level object, but but the listener methods are passed the user's HttpSession in the SessionEvent object.

One thing that might prove difficult is that since it deals with sessions and not HTTP requests, you won't know the specific user's identity at that point since the primary way to get a user's identity for container-based logins is to invoke getRemoteUser() on an incoming HttpServletRequest. You should be able to work around that by adding a request filter to the webapp that pulls the user ID from the request and stores it in your Session as a Session-scope object. Because login is required BEFORE a URL request can be sent to the webapp, and login creates a session if none exists, you should be able to depend on the request listener having a session waiting for you.

[Paul Clapham]

Rajkamal Pillai wrote:Well I am working with a web application. SO once the session has been invalidated the user would be redirected to the login screen?

That's a reasonable way to test that a session has expired. Of course you would first have to make no accesses to the web server for a time exceeding the supposed time-out settings, and only then send a request to test whether it is redirected to the login screen.

[Tim Holloway]

Paul Clapham wrote:

Rajkamal Pillai wrote:Well I am working with a web application. SO once the session has been invalidated the user would be redirected to the login screen?

That's a reasonable way to test that a session has expired. Of course you would first have to make no accesses to the web server for a time exceeding the supposed time-out settings, and only then send a request to test whether it is redirected to the login screen.

Another option is to put a log message in the HttpSessionListener. Assuming your webapp has a logger configured (and it should!) then output a message to the application's log when the session has been invalidated. And since typically loggers format messages with timestamps on them, you should know to the second when that happens.

[Tim Holloway]

Note that if a session has expired and you've been logged out by the container you will only get a login prompt IF your next URL request is secured.

I often have one or more public pages in my webapps and they do not require a user to be logged in to access them. Only when the user requests a secured page URL will the login screen be displayed.

[Rajkamal Pillai]

Sir(s),

Thank you for your advice.
Allow me to beg to disagree, may I?
At this point I do not have an User Object nor can I afford all the world complaining about the app taking too much of time to just login. By the way that would be a change in behavior.
Obviously no app can do any more than what the server supports.
My simple question here is what other option do I have?

I totally respect Tim's advice , though I should add at this point I do not have any User and everybody logging in is about to go through the same pain?

[Paul Clapham]

It looks like I totally don't understand your question at all. What's this "User" object you're talking about? (I don't see anybody in the thread mentioning such a thing.) And what's this login process which requires an unconscionable amount of time to run? (I don't see anything about that in the thread either.) So I'm confused. I thought the question was about how to modify the interval before the server times out a session.

[Ron McLeod]

Rajkamal Pillai wrote:The issue I face is that the value set through

setMaxInactiveInterval()

does not have appear to have much effect.
Remember reading that the timeout value will be defaulted to the value in web.xml (by a Tomcat process?).

Am I correct and is there any way around this?

I'm really sure where you are at now - after doing some testing, I am going to reply your original question.

Yes, HttpSession#setMaxInactiveInterval does change affect the timeout period for an inactive session.  Running Tomcat version 9.0.73.0, I observed that the the session will timeout (and be destroyed) sometime after the specified interval.  It appears like with the version of Tomcat that I was running, that a timeout check is performed every 60 seconds, so the actual time when the session is declared invalid can be up to 60 seconds after what you might expect.

Test setup:
<?xml version="1.0" encoding="UTF-8"?> <web-app version="4.0" xmlns="http://xmlns.jcp.org/xml/ns/javaee"   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"   xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee   http://xmlns.jcp.org/xml/ns/javaee/web-app_4_0.xsd">  <session-config>    <session-timeout>5</session-timeout>  </session-config> </web-app>

import java.time.Instant;
import java.time.LocalDateTime;
import java.time.ZoneId;

import javax.servlet.annotation.WebListener;
import javax.servlet.http.HttpSession;
import javax.servlet.http.HttpSessionEvent;
import javax.servlet.http.HttpSessionListener;

@WebListener
public class SessionListener implements HttpSessionListener {
    final static boolean SET_INTERVAL = true;
    final static int NEW_INTERVAL_SECONDS = 120;

    public void sessionCreated(final HttpSessionEvent event) {
        var session = event.getSession();
        session.setAttribute("StartTs", System.currentTimeMillis());
        if (SET_INTERVAL) {
            session.setMaxInactiveInterval(NEW_INTERVAL_SECONDS);
        }
        System.out.printf("SessionListener.sessionCreated() %s%n", getMessage(session));
    }

    public void sessionDestroyed(final HttpSessionEvent event) {
        var session = event.getSession();
        System.out.printf("SessionListener.sessionDestroyed() %s%n", getMessage(session));

        long startTs = (long) session.getAttribute("StartTs");
        var lifetimeMillis = System.currentTimeMillis() - startTs;
        System.out.printf("SessionListener.sessionDestroyed() session lifetime: %s%n", 
                lifetimeMillis /1000);
    }

    String getMessage(HttpSession session) {
        var now = millisToPrintableTime(System.currentTimeMillis());
        var sessionId = session.getId();
        var creationTime = millisToPrintableTime(session.getCreationTime());
        var lastAccessedTime = millisToPrintableTime(session.getLastAccessedTime());
        var maxInactiveInterval = session.getMaxInactiveInterval();
        return String.format("now: %s, id: %s, cr: %s, la: %s, mii: %s",
                now, sessionId, creationTime, lastAccessedTime, maxInactiveInterval);
    }

    String millisToPrintableTime(long millis) {
        return LocalDateTime.ofInstant(Instant.ofEpochMilli(millis), ZoneId.systemDefault())
                .toLocalTime().toString();
    }
}

Max inactive interval not setSessionListener.sessionCreated() now: 22:08:48.928, id: B02C344A199CB1B7ED9D0C5695B13823, cr: 22:08:48.928, la: 22:08:48.928, mii: 300 SessionListener.sessionDestroyed() now: 22:14:34.912, id: B02C344A199CB1B7ED9D0C5695B13823, cr: 22:08:48.928, la: 22:08:48.930, mii: 300 SessionListener.sessionDestroyed() session lifetime: 345 Max inactive interval set to 60 (notice how all sessions expire at 55 second mark)SessionListener.sessionCreated() now: 22:19:09.595, id: AE049285AC432E302C93F65A1D23667A, cr: 22:19:09.594, la: 22:19:09.594, mii: 60 SessionListener.sessionDestroyed() now: 22:20:55.021, id: AE049285AC432E302C93F65A1D23667A, cr: 22:19:09.594, la: 22:19:09.597, mii: 60 SessionListener.sessionDestroyed() session lifetime: 105 SessionListener.sessionCreated() now: 22:21:05.396, id: 5422AA35D74311FE10A92F9DEF6D6FF1, cr: 22:21:05.396, la: 22:21:05.396, mii: 60 SessionListener.sessionDestroyed() now: 22:22:55.035, id: 5422AA35D74311FE10A92F9DEF6D6FF1, cr: 22:21:05.396, la: 22:21:05.398, mii: 60 SessionListener.sessionDestroyed() session lifetime: 109 SessionListener.sessionCreated() now: 22:23:26.101, id: 2E7991A7C62DA0FCF7078D885F02C399, cr: 22:23:26.100, la: 22:23:26.100, mii: 60 SessionListener.sessionDestroyed() now: 22:24:55.047, id: 2E7991A7C62DA0FCF7078D885F02C399, cr: 22:23:26.100, la: 22:23:30.176, mii: 60 SessionListener.sessionDestroyed() session lifetime: 88Max inactive interval set to 60 (session activity after 21 seconds; created and last accessed different)SessionListener.sessionCreated() now: 22:25:40.738, id: C8B937CD0FEE09EBE534B863E258DFA4, cr: 22:25:40.737, la: 22:25:40.737, mii: 60 SessionListener.sessionDestroyed() now: 22:27:55.066, id: C8B937CD0FEE09EBE534B863E258DFA4, cr: 22:25:40.737, la: 22:26:01.742, mii: 60 SessionListener.sessionDestroyed() session lifetime: 134Max inactive interval set to 120SessionListener.sessionCreated() now: 22:31:40.380, id: 66C13EAE17FD031D1F17112641AF821F, cr: 22:31:40.379, la: 22:31:40.379, mii: 120 SessionListener.sessionDestroyed() now: 22:34:25.188, id: 66C13EAE17FD031D1F17112641AF821F, cr: 22:31:40.379, la: 22:31:40.381, mii: 120 SessionListener.sessionDestroyed() session lifetime: 164

[Rajkamal Pillai]

Paul Clapham wrote:Is your problem that users are logged out based on the default rather than the override, or that they aren't logged out at all if there's an override, or something else?

Yes, my issue is that Users are logged off after (the default) 30 seconds.

session.setMaxInactiveInterval(300)

Does not have any effect at all.

[Rajkamal Pillai]

Paul Clapham wrote:It looks like I totally don't understand your question at all. What's this "User" object you're talking about? (I don't see anybody in the thread mentioning such a thing.) And what's this login process which requires an unconscionable amount of time to run? (I don't see anything about that in the thread either.) So I'm confused. I thought the question was about how to modify the interval before the server times out a session.

Paul,

Your understanding is correct! By User object, I mean that my application loads up a User containing relevant information and permissions. Now when I say I do not have access to a User object I mean that the timeout interval is associated with a User and saved in the database.  So extending

sessionDestroyed()

I would not have a way to load the timeout interval for this particular User? Also I wonder whether going the Filter approach or SessionListener) would negatively affect multiple Users.

My question is about how to modify the timeout interval dynamically, other than by making changes to web.xml. What worries me is my suggested solution should not cause performance and/or usability side effects.

[Rajkamal Pillai]

Ron,

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

[Rajkamal Pillai]

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

[Paul Clapham]

Rajkamal Pillai wrote:My question is about how to modify the timeout interval dynamically, other than by making changes to web.xml. What worries me is my suggested solution should not cause performance and/or usability side effects.

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.

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.

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.

[Rajkamal Pillai]

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:

[Tim Holloway]

OK. Now I have to ask.

Are you actually using JEE security or are you running some other login system?

Because you say you have this User object, but JEE (Tomcat) doesn't create any "User" object and certainly doesn't load one.

Moreover, since there's no login event to hook into, it's not likely that your User is getting loaded when they login.

So please explain.

It you're using an alternate security system such as Spring Boot or (shudder) Do-It-Yourself login (security Red Alert!!!) we need to know that so we can respond accordingly.

Sessions time out regardless, but if you're not using the container security system, your "log out" isn't actually going to be a JEE logout.

[Rajkamal Pillai]

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!

[Ron McLeod]

Rajkamal Pillai wrote:My default session timeout value is set to 30 in web.xml, so -
<session-timeout>30</session-timeout>
I understand that this is applicable across all user sessions.

Yes - that setting will cause sessions to timeout after 30 minutes of inactivity (unless overridden on a per-session basis using HttpSession#setMaxInactiveInterval after the session has been created).

Rajkamal Pillai wrote:... my issue is that Users are logged off after (the default) 30 seconds.

session.setMaxInactiveInterval(300)

Does not have any effect at all.

How did you determine this?  In this post I found that HttpSession#setMaxInactiveInterval works as-expected.  I provided the code that I used to prove that it was working as well as test results.  You should be able to use this same code in your environment to test as well.

Rajkamal Pillai wrote:My question is about how to modify the timeout interval dynamically, other than by making changes to web.xml. What worries me is my suggested solution should not cause performance and/or usability side effects.

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

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

I don't think it matters.  I used 9.0.73 to test with because I already had the docker image downloaded.


The title of this thread is: Tomcat server timeout settings not working as expected..  If you can share some details when/how you are overriding the configured default timeout period, and provide some evidence that it is not working properly, then we can probably help more.

[Rajkamal Pillai]

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 Holloway]

Actually, no. I am no more enlightened than before. I'm OK with using "they/their" for abstract person of indeterminate/unimportant gender. What gets me is trying to use it when you're referring to a single specific person standing among a group right next to me. They need a more precise word for that.

Anyway, "login" is being presented as an Accomplished Fact here, but SOMETHING has to be handling the login process. That can be Tomcat itself, a third-part security framework such as Spring Security, or something cobbled up in-house (which is almost guaranteed to be actually not very secure, but that's another matter).

So until we know which type of Authentication System (login)) you're talking about, we can't give accurate answers.

[Rajkamal Pillai]

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.

[Tim Holloway]

If you don't know what security system you are using for Authentication and Authorization, you are already in trouble.

Security isn't automatic or magic. Someone has to set up an A/A system and properly configure it before you can even begin to worry about what happens after you login.

[Rajkamal Pillai]

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.

[Tim Holloway]

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.

[Rajkamal Pillai]

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.

[Rajkamal Pillai]

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?

[Rajkamal Pillai]

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?