On Wed, Feb 12, 2020 at 4:55 PM Klein, Carsten <c.kl...@datagis.com> wrote:
> Hi there, > > actually, Tomcat just does not serialize authentication information, > that is AuthType (BASIC, DIGEST etc.) and the Principal, during session > serialization. That affects session persistence across restarts (no > matter what manager is used) as well as session transfer between cluster > nodes. As a result, persisted and reloaded sessions as well as sessions > transferred between cluster nodes are no longer authenticated. > > I was pointing that out in this mailing list in late 2019 (Topic "Tomcat > 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication > related information"). > > To overcome this, I have a simple solution in mind. It's only about 10 > new lines of code. Basically, it's a new boolean property > 'persistAuthentication' for the manager. Mark Thomas agreed with > optionally saving authentication information along with the persisted > session (only, if the new option is true). He encouraged me to write an > enhancement/patch and provide it as a Pull Request. > > The only problem for me is lack of time. Although the code itself is > quite simple, the things making me holding back are the Git stuff, > making Tomcat build in my Eclipse etc... > Please look at DeltaSession serialization. The use case for persistence of the principal across Tomcat restarts is useless however, so -1. Rémy > > Carsten > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA256 > > > > Jon, > > > > On 2/11/20 9:33 PM, Jonathan S. Fisher wrote: > >> Apologies, I'm not seeing how this helps, I don't see where > >> authentication information is transmitted > > > > No, seriously, what session manager are you using? > > > > - -chris > > > >> On Tue, Feb 11, 2020 at 5:39 PM Christopher Schultz < > >> ch...@christopherschultz.net> wrote: > >> > >> Jon, > >> > >> On 2/11/20 5:36 PM, Jonathan S. Fisher wrote: > >>>>>> What do you mean by logged out If it's one from Redisson, > >>>>>> then you should look at their code and not > >>>>> Tomcat's code. > >>>>> > >>>>> So you have two tomcat nodes: A & B, clustered in any > >>>>> fashion (forget I mentioned redisson) of your choosing; let's > >>>>> say they're clustered using the built in tcp point-to-point > >>>>> replication. > >> The choice of session manager is ... pretty critical, here. So > >> which session manager are you using/ > >> > >>>>> Have 5 people logged into an application on the first server > >>>>> using standard JavaEE APIs (HttpServletrequest.login) Now > >>>>> turn off server A. Your load balancer starts sending traffic > >>>>> to server B. Their sessions will be there, BUT they will be > >>>>> logged out; one has to call HttpServletRequest.login() again. > >>>>> Upon login, Tomcat destroys the previous session (as it > >>>>> should), nullifying any benefit for clustering the > >>>>> application in the first place. > >> Tomcat does not destroy sessions when authenticating. > >> > >>>>> In the two links I provided, the StandardSession object goes > >>>>> to great length to ensure that the security principal is not > >>>>> serialized into the session > >> > >> True. > >> > >>>>> and therefore [not] replicated in the cluster. > >> > >> False. > >> > >>>>> Why is that? Why not serialize the security credential so the > >>>>> user can bounce between servers? > >> > >> Authentication information is transmitted in a different way. > >> > >> I would really encourage you to look at the code for DeltaManager, > >> which is the session manager typically used for clustering in > >> Tomcat. If you are not using the DeltaManager, then you need to > >> look at the code being used for your actual SessionManager. > >> > >> -chris > >> > >>>>> On Tue, Feb 11, 2020 at 4:27 PM Christopher Schultz > >>>>> <ch...@christopherschultz.net > >>>>> <mailto:ch...@christopherschultz.net>> wrote: > >>>>> > >>>>> Jon, > >>>>> > >>>>> On 2/11/20 2:35 PM, exabrial wrote: > >>>>>> https://stackoverflow.com/questions/59833043/tomcat-logs-user-out- > > dur > >> > >>>>>> > > i > >>>>> > >>>>>> > >> ng-session-failover-event-and-restarts > >>>>> <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out- > > dur > >> > >>>>> > > ing-session-failover-event-and-restarts > >> <https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-dur > > ing-session-failover-event-and-restarts> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >> > > We've implemented session replication using Redisson, but we > >>>>> noticed > >>>>>> that if we intentionally fail a node, the user's sessions > >>>>>> do get replicated, but they're logged out when they're > >>>>>> restored on the new server. > >>>>> > >>>>> What exactly do you mean when you say "logged-out"? > >>>>> > >>>>>> Is there a way to make this work properly so the user > >>>>>> doesn't get logged out during a failover event? > >>>>> > >>>>>> Most /More importantly, is there a technical or security > >>>>>> reason for this? > >>>>> > >>>>> FYI the servlet specification does not guarantee that > >>>>> <distributable> web applications also transfer > >>>>> authentication information. > >>>>> > >>>>>> If you look at the Tomcat code, they actively try and > >>>>>> avoid serialization the Security Principal: > >>>>> > >>>>>> https://github.com/apache/tomcat/blob/master/java/org/apache/catal > > ina > >> > >>>>>> > > / > >>>>> > >>>>>> > >> session/StandardSession.java#L1559 > >>>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/catal > > ina > >> > >>>>> > > /session/StandardSession.java#L1559 > >> <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina > > /session/StandardSession.java#L1559> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >> > > https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/ > >> se > >>>>> > >>>>> > >> ssion/StandardSession.java#L234 > >>>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/catal > > ina > >> > >>>>> > > /session/StandardSession.java#L234 > >> <https://github.com/apache/tomcat/blob/master/java/org/apache/catalina > > /session/StandardSession.java#L234> > >>>>> > >>>>> > >>>>> > >> > > That code is for serializing the whole session, not transmitting > >>>>> session information between cluster nodes. You need to read > >>>>> the code for the various ClusterManagers and (more > >>>>> importantly), the DeltaSession class. > >>>>> > >>>>> Which SessionManager are you using? If it's one from > >>>>> Redisson, then you should look at their code and not Tomcat's > >>>>> code. > >>>>> > >>>>> -chris > >>>>> > >>>>> > >>>>> > >>>>> -- Jonathan | exabr...@gmail.com <mailto:exabr...@gmail.com> > >>>>> Pessimists, see a jar as half empty. Optimists, in contrast, > >>>>> see it as half full. Engineers, of course, understand the > >>>>> glass is twice as big as it needs to be. > >>> > >>> --------------------------------------------------------------------- > >>> > >>> > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: users-h...@tomcat.apache.org > >>> > >>> > >> > > -----BEGIN PGP SIGNATURE----- > > Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ > > > > iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EGYMACgkQHPApP6U8 > > pFgewxAAimutw1exjBFgtBUUvj4I05KUH/Sy8G4TSXcUuYJv0pVGv2oztzNXp/Cz > > IcJdj/mSDdg2c4TdLdsk9F2PCPOJdevmygJQbArcsgZd/X+RG8ZwPrZVJ26DweOJ > > vrB8RsP/VDiXU4JJKjxN1SyIIWB9NRXpvGwUWsb8WTQosQFk94rq4N8XIQ2CGx8F > > CgHu27Rn9/gTZv5tWscWKXK9mWfUsLoWJIbHz+ApfT4bKTop84trf4U2A5ug1jdF > > c6eRZU2p9+TJuThOU0Mbt2akN9c7hYIYo6KZ8kpXV+zh1NteGlYYsDXKGP6lQsDL > > 5p5jvMVnKNPY00sz79XYhaqpU58kSSWGSy15AB1bMMmqQ9vs5QUKLJhJy8ZkMID6 > > 5C/lDZe3hTlIn/E7NZyvBC27XVTh5ofUUviRUvNoMVPjPAw7QpNIzhtIrjgviBjp > > uV7N1eEIA7jUGaVsH7a1/N+RxwCMqr31bfrr/kCTq9iBB2gvYAQXxAVTlkdj2bYQ > > 06ZmHpOAh1skqgLqMKIPI0p0EngN7XRYUCfu75AHgIcIqfYuc47DXqgeCKs5/sCk > > iW+n9jpQ2r7/wgozPhO8Gnsve7ktjH3G58YBeBwUTB2hrVLDuCpuchmjPqJJaNfq > > Fr7kAuGLqqBTUxnYpQiQPml8OzH2QSn0/z7yuRkm6ZfKsPpQSKM= > > =ArT1 > > -----END PGP SIGNATURE----- > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > > For additional commands, e-mail: users-h...@tomcat.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
