Bug 68742

Summary: SingleSignOn session invalidation logic fallacy results in 408 request timed out.
Product: Tomcat 9 Reporter: Or Messer <messeror>
Component: CatalinaAssignee: Tomcat Developers Mailing List <dev>
Severity: normal    
Priority: P2    
Version: 9.0.x   
Target Milestone: -----   
Hardware: PC   
OS: All   

Description Or Messer 2024-03-10 10:56:10 UTC
I'm going to describe the bug as I understand it happens:

Tomcat runs 3 applications, all of which require a session and are unified in a SSO session.

Define 3 apps:
API - the api
ROOT - creates a session and just redirects to the front
FRONT - handles the frontend

1. User logs in and receives all of the session cookies including the SSO cookie.

2. User doesn't use the app for a while and the SSO cookie expires, which redirects to the login page.

3. ONLY the SSO session is invalidated in the client-side and that is the only session that gets deleted for the client.

4. When accessing the login page, the user accesses the API and the FRONT apps which results in them getting a new session for those. User doesn't access the ROOT app and doesn't get a new session for that app (still has the old session)

5. User tries to login and gets a 408 request timed out because he is trying to login with j_security_check using an already invalidated ROOT session.

I can't think of a single reason, that when the SSO session is invalidated, why not invalidate all of the session which make up that SSO session (in the client side).

Why let the client side keep the session cookies for the other sessions when the SSO one is invalidated. 

I do understand that the user just needs to send a request to any of the apps to receive a new session and I resolved this by just adding a fetch() call to that app. But I still can't think of a reason that tomcat doesn't tell the browser to invalidate all of the sessions which corelate to that SSO session.

Would love some clarification and a possible fix?
Comment 1 Remy Maucherat 2024-04-08 14:45:14 UTC
There are too many factors here. Can you provide the sso config from server.xml as well as the three test webapps ?
There are three webapps so three separate sessions. SSO would share auth, but here it seems you have an issue completing FORM auth due to some session expiration. If auth fails, then no auth, then nothing to SSO.
Comment 2 Mark Thomas 2024-05-03 12:50:32 UTC
If sufficient information is not provided to enable this issue to be recreated the bug report will get resolved as INVALID or WORKSFORME.
Comment 3 Mark Thomas 2024-05-23 09:00:12 UTC
No response for over a month. Resolving as WORKSFORME.

If this is still an issue then it can be re-opened if the requested information is provided.