Re: Tomcat doesn't propogate Security Credentials during session failover

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon,

On 2/12/20 12:34 PM, Jonathan S. Fisher wrote:
> So the manager would be this, I've noticed it uses the
> StandardSession, which explicitly prevents serialization of the
> user principal and auth type:
> org.redisson.tomcat.RedissonSessionManager

Thank you.

> Two questions, on org.apache.catalina.Session, do the values
> getNote and setNote replicate across the cluster by default?

No, but it's important you understand that you don't have a "Tomcat
cluster". You have whatever you get when you use
RedissonSessionManager. I guess you could call it a "Redisson
Cluster". A "Tomcat Cluster" does indeed transmit user Principals
across the cluster to other nodes. the fact that Redisson isn't really
a bug in Tomcat.

> I'm curious if we could solve this whole thing with a valve that 
> copies the principal into the org.apache.catalina.Session or the 
> HttpSession.
Possibly.

> Next, Chris are you saying RedissonSessionManager should use their
> own implementation of StandardSession that preserves the
> principal?

Not necessarily.

But if Redisson is responsible for handling session data around your
cluster, then it needs to actually do so. Note that packaging-up the
whole session object and blasting it around to the other nodes isn't
exactly recommended technique. That's why (a) you don't see
StandardSession saving its Principal when it's serialized and (b) the
DeltaManager/DeltaSession don't work this way. They are called "delta"
because they send only the differences around to the other clusters.

Redisson could certainly propagate user Principals around the cluster
if it wanted to do so. Implementing it there would make much more
sense than changing Tomcat's StandardSession serialization mechanism
to include the Principal and then sending the whole session during
every interaction.

> I guess I never got the questions answered, why isn't this the 
> default behavior? It seems tomcat goes well out of its way to *not 
> serialize *the principal. I was wondering if there was a reason
> for that.
It might be surprising to find that your credentials are stored on the
disk when you write a session there. This is a security consideration.
If you want to get around that restriction, you have to work for it.

- -chris
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5EPZsACgkQHPApP6U8
pFgrvQ/8CWmo9UM6zpxJxnrr3FYJb1bPq5JymxPVjKJ7qQRi108DjUSsk5/GRKjC
z1iXI9dn6UE3hbwQ9OGlzCmofJG7orHTS88h24PuswkpBa786NUIFmcAReIOsBKm
Jy347p9blSkVMGBDd3CxQv2QddMO1vqdbvBBU1KdtH0/hhZxDYGW0lNcwN+8xhrh
6Z6jKXeTx/E2BYA6wM8sOTl6J+h0x/dzIEFPPqV7/R53RQzADw32cawzASJm8Gh7
dzn3NiokaRGPxLIIzV7+IETyUxOS3n1zxIObkPflxmCB2NBSiWCi15W89al9scdO
uG17pvCkl2A/WSfyhUDreYqlx/45jiNYarKCR9vU6NKqZfJm1I+LW24zQK9543dd
PfUbvVIl0JHrMjbVMNwql8QoH++oIjT+T8urW+d2BkdWLtsExicN3s6n4Ujwl5NO
hX14hYw91Mma3BuTe0RfO06RapJnfmsS7GowJ0m+0SFe4mIoCuz1G/1CDDXhMsw2
frRsNd0MARSj4VjrdQtud1M2vdDpUti0O/oIDJ4amuB28kBkvPfmPsNWTtvqurJG
JcTp6dv5JBziAie34yFUU5kDtTyI1t+gUuMDtEC3xrd0FCulrer3/zzv9uUDI/gA
IqveymzQk1lgp64XFAaxyXvoZaFDCsQu0kQhTvFcJgiv4/vvOog=
=MWhB
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat doesn't propogate Security Credentials during session failover

[Klein, Carsten]

Jonathan,


So the manager would be this, I've noticed it uses the StandardSession,
which explicitly prevents serialization of the user principal and auth
type: org.redisson.tomcat.RedissonSessionManager

Two questions, on org.apache.catalina.Session, do the values getNote and
setNote replicate across the cluster by default? I'm curious if we could
solve this whole thing with a valve that copies the principal into
the org.apache.catalina.Session or the HttpSession.

Next, Chris are you saying RedissonSessionManager should use their own
implementation of StandardSession that preserves the principal? I guess I
never got the questions answered, why isn't this the default behavior? It
seems tomcat goes well out of its way to *not serialize *the principal. I
was wondering if there was a reason for that.


Mark gave me kind of an answer when I was stumpling over the same issue. 
Read these mails:


http://tomcat.10.x6.nabble.com/Tomcat-7-x-x-8-x-x-8-5-x-and-9-x-x-Session-serialization-w-o-authentication-related-information-td5092247.html

Carsten



Thanks!




On Wed, Feb 12, 2020 at 10:07 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:


-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
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

Re: Tomcat doesn't propogate Security Credentials during session failover

[Jonathan S. Fisher]

So the manager would be this, I've noticed it uses the StandardSession,
which explicitly prevents serialization of the user principal and auth
type: org.redisson.tomcat.RedissonSessionManager

Two questions, on org.apache.catalina.Session, do the values getNote and
setNote replicate across the cluster by default? I'm curious if we could
solve this whole thing with a valve that copies the principal into
the org.apache.catalina.Session or the HttpSession.

Next, Chris are you saying RedissonSessionManager should use their own
implementation of StandardSession that preserves the principal? I guess I
never got the questions answered, why isn't this the default behavior? It
seems tomcat goes well out of its way to *not serialize *the principal. I
was wondering if there was a reason for that.

Thanks!




On Wed, Feb 12, 2020 at 10:07 AM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -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
> 

Re: Tomcat doesn't propogate Security Credentials during session failover

[Christopher Schultz]

-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 
>>> >> > 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
>>> 
>>> 
dur
 
>>> 
> ing-session-failover-event-and-restarts
 
 
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

Re: Tomcat doesn't propogate Security Credentials during session failover

[Rémy Maucherat]

On Wed, Feb 12, 2020 at 4:55 PM Klein, Carsten  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
> >  > > 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
> >  > dur
> >>
> >
> > ing-session-failover-event-and-restarts
> >>  > 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 do

Re: Tomcat doesn't propogate Security Credentials during session failover

[Klein, Carsten]

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...


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
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













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
 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/catalina/

se




ssion/StandardSession.java#L234

Re: Tomcat doesn't propogate Security Credentials during session failover

[Christopher Schultz]

-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 
 >>> > 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
 
 
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 
  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
 
 
/session/StandardSession.java#L1559
> 





> 
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/
> se
 
 
> ssion/StandardSession.java#L234
 
 
/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  
 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-

Re: Tomcat doesn't propogate Security Credentials during session failover

[Jonathan S. Fisher]

Apologies, I'm not seeing how this helps, I don't see where authentication
information is transmitted

On Tue, Feb 11, 2020 at 5:39 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> 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
> >  > > 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
> >  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
> >  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/catalina
> /
> >
> >>
> session/StandardSession.java#L1559
> >  /session/StandardSession.java#L1559
> 
> >
> >
> >
> >
> > https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/
> se
> >
> >
> ssion/StandardSession.java#L234
> >  /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 
> > 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.
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5DOyEACgkQHPApP6U8
> pFg1Pg//SXlXbzvMMRJ281amJdiwZ+k9n5GJYBzXBUlmk6KnPY9yw1hovw1/Bshb
> N/5qyjlcyCAtYCcuexJlvk06APgWPAgLtrXdg+mLW1yca7ic/OGcAnWi7u2ULSz3
> dBjWucWDwNLPI27zs0wfDwCh9F+Bx5tOzShKaSNeghevazABFsAd7HQOEIoauv1t
> Ccq0DxuBHufiZn4vXwCPeFSaeQI/OGOUj1W

Re: Tomcat doesn't propogate Security Credentials during session failover

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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 
>  > 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
> 
>
> 
> 
> 
> 
> 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
>  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/catalina
/
>
>> 
session/StandardSession.java#L1559
> 
>
> 
> 
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/
se
>
> 
ssion/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  
> 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.
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5DOyEACgkQHPApP6U8
pFg1Pg//SXlXbzvMMRJ281amJdiwZ+k9n5GJYBzXBUlmk6KnPY9yw1hovw1/Bshb
N/5qyjlcyCAtYCcuexJlvk06APgWPAgLtrXdg+mLW1yca7ic/OGcAnWi7u2ULSz3
dBjWucWDwNLPI27zs0wfDwCh9F+Bx5tOzShKaSNeghevazABFsAd7HQOEIoauv1t
Ccq0DxuBHufiZn4vXwCPeFSaeQI/OGOUj1WenJWo6CSGM/Qlr8bf5n0uHYqV9ltx
uz9SXEYerqpvQxQYeGsdMQ87U8hItucgNYwcqf+VC1Ky4YllcaaAsWNxKx8ULEcQ
7uNJx3Okth/+/Dq9ZA0wb8aT0joAOq16cJZgZQKMmqaSdc9gY14YD9dM00QeyNSD
OXxPGcM093/ShNFHiilOhk9x5AjwIxHHCxI2Lt4p8NvZyzlRSOTr+XSCBauHmS4H
JY6vJGPhbgcmmFt5k3EIoSZs1jEKOjqyK7sEVqcsl1cWedLml/rJwnupEzIC6WF2
QLo+zNL/Bu3rVAu1xde7cdIPZf1zVX7grURdLCl1DXEyrXrjzj6b1YZr5IDsNVGX
nygTk8mpB5oEWjX6oNMXFBGCjVO2xC843oRgXBDt0ql8pHQ1T8crP5IAzEAcgJm/
uBVaFVOvWG0g6CrK4B+rZQxxjbm0Tczw9DrzoAyb1Vd0X/gc1nE=
=5Xd8
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Tomcat doesn't propogate Security Credentials during session failover

[Jonathan S. Fisher]

> 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. 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.

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, and therefore replicated in the cluster. Why is that? Why not
serialize the security credential so the user can bounce between servers?



On Tue, Feb 11, 2020 at 4:27 PM Christopher Schultz <
ch...@christopherschultz.net> wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Jon,
>
> On 2/11/20 2:35 PM, exabrial wrote:
> > https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-duri
> ng-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 
> 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/catalina/
> session/StandardSession.java#L1559
> 
> >
> >
> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/se
> ssion/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
> -BEGIN PGP SIGNATURE-
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5DKmgACgkQHPApP6U8
> pFj5fA/+MtxPWjtoiRCcfPJSvjdZjjZA1PbiTPSxXqtizg17071kQJVXy3GONP6O
> AONwDkm/+2yNo6RJvRH2WW5qLZgX9FvNekUVkDeM+MvNOwszqAx/doXgCwO1ljy3
> Dv1uOgWCGE2ktAig3Cul9BICGmq6hhcfI9yT0oicrrxKI9njpVKhhJijLvJEZNFp
> GeSwU2QMRR25asinBvCJ2L6wMFM5ppXjpwoWVvI1G+UlFYEUOZAAlNAsq/Dblmuo
> 45GrNQdw2LyKfjt/lLaQrjEOx3KoHtfIKBOxSBgwJFykx/w3RmoEXONrwj6tuTyG
> HVSvLITH0rky301YvXPqrEAseW0816grwbCkP1HrmDfbpVCQ/1QUb+ceKEHzLuOr
> 8XPha3M0xDhFF9daEqJcYurcIC6NCMy0UuvaSfvh3ICy/RFL2K4Sql9SRGnj4eLV
> 8QJTMHgKDD3Gie2wHr9gYDwj7gtkjHGJrMyCNOh1bTNSQKkabFlsUL1uiEOJ0QgR
> EkLketZAhWNGMiaS4X41jtqQymL5zJI7P7KqGy0LmuZErZt6qot/5If0osgnl1V+
> wjP6YjBU2i9YajNJB57JFtx3AkCRXUXZm4vAQnG8v//ECsWOrggdlQvF+W5r2mXr
> 50z5n2LUbUrKTX9N3ailoNczmZ/MyEhUhyTT7xmqSjLXtlFPO7g=
> =UkyD
> -END PGP SIGNATURE-
>


-- 
Jonathan | 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.

Re: Tomcat doesn't propogate Security Credentials during session failover

[Christopher Schultz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jon,

On 2/11/20 2:35 PM, exabrial wrote:
> https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-duri
ng-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 
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/catalina/
session/StandardSession.java#L1559
>
> 
https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/se
ssion/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
-BEGIN PGP SIGNATURE-
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl5DKmgACgkQHPApP6U8
pFj5fA/+MtxPWjtoiRCcfPJSvjdZjjZA1PbiTPSxXqtizg17071kQJVXy3GONP6O
AONwDkm/+2yNo6RJvRH2WW5qLZgX9FvNekUVkDeM+MvNOwszqAx/doXgCwO1ljy3
Dv1uOgWCGE2ktAig3Cul9BICGmq6hhcfI9yT0oicrrxKI9njpVKhhJijLvJEZNFp
GeSwU2QMRR25asinBvCJ2L6wMFM5ppXjpwoWVvI1G+UlFYEUOZAAlNAsq/Dblmuo
45GrNQdw2LyKfjt/lLaQrjEOx3KoHtfIKBOxSBgwJFykx/w3RmoEXONrwj6tuTyG
HVSvLITH0rky301YvXPqrEAseW0816grwbCkP1HrmDfbpVCQ/1QUb+ceKEHzLuOr
8XPha3M0xDhFF9daEqJcYurcIC6NCMy0UuvaSfvh3ICy/RFL2K4Sql9SRGnj4eLV
8QJTMHgKDD3Gie2wHr9gYDwj7gtkjHGJrMyCNOh1bTNSQKkabFlsUL1uiEOJ0QgR
EkLketZAhWNGMiaS4X41jtqQymL5zJI7P7KqGy0LmuZErZt6qot/5If0osgnl1V+
wjP6YjBU2i9YajNJB57JFtx3AkCRXUXZm4vAQnG8v//ECsWOrggdlQvF+W5r2mXr
50z5n2LUbUrKTX9N3ailoNczmZ/MyEhUhyTT7xmqSjLXtlFPO7g=
=UkyD
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Tomcat doesn't propogate Security Credentials during session failover

[exabrial]

https://stackoverflow.com/questions/59833043/tomcat-logs-user-out-during-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.

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?

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/catalina/session/StandardSession.java#L1559

https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/session/StandardSession.java#L234



--
Sent from: http://tomcat.10.x6.nabble.com/Tomcat-User-f1968778.html

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org