Bug 57338 - SingleSignOnEntry cache of ClusterSingleSignOn valve is not synchronized on Tomcat startup
Summary: SingleSignOnEntry cache of ClusterSingleSignOn valve is not synchronized on T...
Status: RESOLVED FIXED
Alias: None
Product: Tomcat 7
Classification: Unclassified
Component: Cluster (show other bugs)
Version: 7.0.57
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
: 28039 (view as bug list)
Depends on:
Blocks:
 
Reported: 2014-12-10 17:58 UTC by Aaron Ramsey
Modified: 2015-04-22 10:36 UTC (History)
1 user (show)


Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Ramsey 2014-12-10 17:58:51 UTC 
When using the ClusterSingleSignOn valve, it looks like the single sign on session state is not synchronized to cluster nodes when they start. The state is instead only replicated at the moment that an action is performed, so any nodes that come online after that action are out of sync.

See mailing list discussion here: http://www.mail-archive.com/users@tomcat.apache.org/msg115472.html
Comment 1 Mark Thomas 2014-12-15 19:59:56 UTC 
Anyone working on this? If not I'll take a look. My initial thoughts are to make use of one of the ReplicatedMap implementations.
Comment 2 Keiichi Fujino 2014-12-16 02:00:44 UTC 
Not yet.
I've just ClusterSingleSignOn implements ClusterValve.(r1645595)
I am writing a document of ClusterSingleSignOn now.

IMHO.
If using the ReplicatedMap, it may be necessary to add jvmRoute to SSOID.
If using SSO cache (ReplicatedMap) of backup node, it will be replicated to the other node.
So, It may be necessary that the SSO Cookie is sticky.

For example, setting the SSO Cookie name(JSESSIONIDSSO) to session_cookie of mod_jk.
As a Result, all of the Web applications in the SSO can be used on the same node,
I think to be able to suppress unnecessary replication.
Comment 3 Mark Thomas 2014-12-16 09:18:52 UTC 
The biggest problem I can see with ReplicatedMap at this point as that I don't want to / can't replicated the two Maps (cache and reverse) as currently implemented since that means replicating the entire session and a potentially non-serializable Principal.

I'm looking into refactoring the SSO implementation to make this easier.

Regarding adding jvmRoute to the SSO cookie, I see the point you are making and I agree with it. However, I think that point applies irrespective of this bug report and is probably best handled separately.
Comment 4 Mark Thomas 2014-12-16 17:34:13 UTC 
I have a patch but it is untested. I'm working on that now and hope to be able to commit something in the next 24 hours.
Comment 5 Mark Thomas 2014-12-16 21:58:19 UTC 
This is currently implemented in trunk (Tomcat 9).

We need to discuss on the dev list which versions, if any, this can be back-ported to as there were a number of fairly invasive changes made to enable this to be implemented sensibly.
Comment 6 Mark Thomas 2014-12-19 14:56:13 UTC 
I've back-ported the fix to 8.0.x and it will be included in 8.0.x onwards. I'll wait for some feedback on that before back-porting it to 7.0.x.
Comment 7 Mark Thomas 2015-02-01 19:33:00 UTC 
*** Bug 28039 has been marked as a duplicate of this bug. ***
Comment 8 Aaron Ramsey 2015-04-20 14:34:47 UTC 
(In reply to Mark Thomas from comment #6)
> I've back-ported the fix to 8.0.x and it will be included in 8.0.x onwards.
> I'll wait for some feedback on that before back-porting it to 7.0.x.

Just wondering...has there been any more thought to back-porting this fix to 7.0.x?
Comment 9 Mark Thomas 2015-04-22 09:02:50 UTC 
It has been long enough now without any issues being reported so I'll start work on the back-port.
Comment 10 Mark Thomas 2015-04-22 10:36:46 UTC 
Fixed in 7.0.x/trunk for 7.0.62 onwards.