I examined the code of ClusterSingleSignOn. This behavior seems to be bug. There seems to be some other problems. a) When a new node is started, SingleSignOnEntry of cache is not replicated. (you mentioned.) b) ClusterSingleSignOn does not implement ClusterValve. c) Unsupported to BackupManager. d) There are no documents.
In order to resolve this problem(a), it must be synchronized between cluster nodes cache of SingleSignOnEntry at startup. Please open a bug entry for a). 2014-12-05 3:35 GMT+09:00 Aaron R <aaron14.pub...@gmail.com>: > Hello, > > I have a Tomcat cluster (7.0.42) that is configured to use the DeltaManager > for session replication. It also uses the ClusterSingleSignOn valve for SSO > and for propagating authentication to the other nodes in the cluster. If I > log into Tomcat1, the session state and the single sign on state are > successfully replicated to Tomcat2, so that when Tomcat1 goes down, the > load balancer switches me to Tomcat2, and I am still authenticated and am > able to access other applications on the server. > > The problem I'm having is that if a new node (Tomcat3) is then brought up > after I have logged in, that new node does not appear to get any SSO state > replicated to it, as I get a 403 error when trying to access a different > application on the server. The regular session state is correctly > replicated to it, but I don't seem to have SSO authentication on this new > server. > > Should this scenario work? Is it possible to get the single sign on state > propagated to nodes that come online after the user has logged in? > > I see one instance of someone mentioning a similar issue in passing a while > back ( > > http://mail-archives.apache.org/mod_mbox/tomcat-users/200809.mbox/%3C15060d5e0809211745s522af93bv153367d9183c6e5e%40mail.gmail.com%3E > ), > but I didn't see any followup after that. > > Thanks, > Aaron > > -- > Keiichi.Fujino >
