Bug 57338 - SingleSignOnEntry cache of ClusterSingleSignOn valve is not synchronized on Tomcat startup
SingleSignOnEntry cache of ClusterSingleSignOn valve is not synchronized on T...
Status: RESOLVED FIXED
Product: Tomcat 7
Classification: Unclassified
Component: Cluster
7.0.57
PC Linux
: P2 normal (vote)
: ---
Assigned To: Tomcat Developers Mailing List
:
: 28039 (view as bug list)
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2014-12-10 17:58 UTC by Aaron Ramsey
Modified: 2015-04-22 10:36 UTC (History)
1 user (show)



Attachments

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.