-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Carsten,
On 2/12/20 10:54 AM, Klein, Carsten wrote: > 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. The DeltaManager does indeed handle this information. Both the AuthType and the Principal. > As a result, persisted and reloaded sessions as well as sessions > transferred between cluster nodes are no longer authenticated. I have to admit, I've never actually set up a Tomcat cluster (because I think it's overkill for my purposes), but the code /is/ there. > 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... Forget Eclipse. We can get you started very easily: $ git clone https://github.com/apache/tomcat $ cd tomcat $ ant deploy (done) - -chris > 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-o ut- > >>>>>>>> dur >>>> >>>>>>>> > i >>>>>>> >>>>>>>> >>>> ng-session-failover-event-and-restarts >>>>>>> <https://stackoverflow.com/questions/59833043/tomcat-logs-user-o ut- > >>>>>>> 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/ca tal > >>>>>>>> ina >>>> >>>>>>>> > / >>>>>>> >>>>>>>> >>>> session/StandardSession.java#L1559 >>>>>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/ca tal > >>>>>>> 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/ >>>> > se >>>>>>> >>>>>>> >>>> ssion/StandardSession.java#L234 >>>>>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/ca tal > >>>>>>> ina >>>> >>>>>>> > /session/StandardSession.java#L234 >>>> <https://github.com/apache/tomcat/blob/master/java/org/apache/catal ina > >>>> /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 >>>>> >>>>> >>>> >> >> --------------------------------------------------------------------- >> >> 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 > -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EIqEACgkQHPApP6U8 pFiEUQ//VSOyYvJeAh4aYLzq7nHwKCtBCMJBDJTdOdttCRBtztmvE1nK1BanBLz8 CVSi0TLPkKjri/tnpnuOvPG7oUv19xG9J1Do7cWxw7mRg/lxk91Ce4oz9aENZIMn 11DoW9TX5itWmmU4l0knGL1IXAKdFkxDPmd+hBAs934pPBeq5rPG/mZd0hQ1s4Qp zeMnVBbX+uX6P2YW5wAGUS5Z4N6Y55BuD6olmV/dOKZ1FyKR76vPYErJ0Aj5tryl G1/5aikwURTdLGFH2lOjaDoChueVrHckbZaaog8z0Vbnv/2eL5xml+AMVs60IYOg da7gVF59WBAvGucpGKCsQn3BFerUgEw1pOPFa3NTT4BrgUvKQmGlGReUSvYASCgP UAPmdtrUvudvnuxRPK8jO9uwLiniqwZ1OZttL+IREeGwKFkYJGphE1akI1XSSL7p 9QKVfIt4wrSWwQke8CxmAjis8J9L1uJ88Uk6nV1cnzxoowdSidStKN3Jv3/prksk cl2GqvcwGKXLt7g5q/DDhuyVpztB+1HpXO3eE7urTuX0lSEnxKuFCiNd4DDJfd5M /EO7tFhtUkYuucGSS8dpN/uGZm61wYlpp2/he5zC7GkX/VKClJ4oNZ+OrEgtJDwU v2ilAJS4czhUN/IrDywNh6Xk1+fdFmrCDtReTTblV19RVFo6vFY= =qmsE -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
