Re: Potential bug in StandardSession and DeltaSession

[Klein, Carsten]

Hi,

forget about the potential bug. Sorry for taking your time. Seems like 
that WriteAbortedException is thrown when reading object data 
occasionally. AFAIK I understand it, it's just like a container 
exception; the actual error is stored in the exception's cause. Uh... 
that's odd...


Carsten


Hi there,

Chris, thanks for your fast GIT introduction :) I took this as a 
(mental) starting point for developing the new 'persistAuthentication' 
option of the Managers (Standard and Persistent). Almost there... I will 
push this branch to my GitHub fork as soon as possible (tomorrow?). 
Maybe you (and also Mark) could have a look at it before I open a 
Bugzilla enhancement?


During that, I may have found a bug in both StandardSession and 
DeltaSession. In both classes, there is a doReadObject method, which 
loads the session from storage. When reading session attributes, the 
code expects de-serialization failures for attribute values. Although 
each class does this a bit differently, both classes do catch a 
WriteAbortedException and log/continue if that exception's getCause() 
returns an instance of NotSerializableException. For any other cause, 
the WriteAbortedException gets re-thrown.


AFAIK, those exceptions are never thrown when reading from an 
ObjectInputStream. Maybe that's a copy and paste bug? Method readObject 
should throw ClassNotFoundException and any subclass of 
ObjectStreamException except WriteAbortedException and 
NotSerializableException.


Carsten

-
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

Potential bug in StandardSession and DeltaSession

[Klein, Carsten]

Hi there,

Chris, thanks for your fast GIT introduction :) I took this as a 
(mental) starting point for developing the new 'persistAuthentication' 
option of the Managers (Standard and Persistent). Almost there... I will 
push this branch to my GitHub fork as soon as possible (tomorrow?). 
Maybe you (and also Mark) could have a look at it before I open a 
Bugzilla enhancement?


During that, I may have found a bug in both StandardSession and 
DeltaSession. In both classes, there is a doReadObject method, which 
loads the session from storage. When reading session attributes, the 
code expects de-serialization failures for attribute values. Although 
each class does this a bit differently, both classes do catch a 
WriteAbortedException and log/continue if that exception's getCause() 
returns an instance of NotSerializableException. For any other cause, 
the WriteAbortedException gets re-thrown.


AFAIK, those exceptions are never thrown when reading from an 
ObjectInputStream. Maybe that's a copy and paste bug? Method readObject 
should throw ClassNotFoundException and any subclass of 
ObjectStreamException except WriteAbortedException and 
NotSerializableException.


Carsten

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

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 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information

[Klein, Carsten]

On 28/11/2019 10:20, Mark Thomas wrote:

On 28/11/2019 08:03, Klein, Carsten wrote:

Hi there,


Thanks for answering my questions. See my remarks inline:

in all recent Tomcat versions the standard session implementation
declares authentication related fields as 'transient', so both the
session's authType as well as it's authenticated Principal is not saved
and restored across restarts.


It isn't just recent versions. It has been that way for 2 decades. All
the way back to Tomcat 4.0.x



I guessed as much.


On those fields there is a comment that clearly describes that:

/**
   * The authenticated Principal associated with this session, if any.
   * IMPLEMENTATION NOTE:  This object is not saved and
   * restored across session serializations!
   */
protected transient Principal principal = null;

However, the comment does not say WHY that information is omitted from
serialization.

It's fine to have session data persisted across restarts, however,
currently, a session is no longer authenticated after a restart (at
least with form login, with which credentials are not sent with every
request).

Actually, at least for my mind, that draws session persistence quite
useless, because, after a restart, the client must re-login prior to use
any resources having a security constraint.


Useless seems a bit strong. The session data is still there. Nothing is
lost. But the user does have to re-enter their credentials to continue
(if the authentication mechanism doesn't do it automatically).

If re-entering the credentials is an issue, have you considered using an
alternative authentication mechanism?



Yes, useless may be too strong. However, we are developing Ajax-driven 
B2B client applications, which terminate / end the session when they 
detect loss of authentication. Technically, these apps periodically send 
keep-alive messages to the server (in order to keep the session alive, 
since with Ajax the server is only queried when data must be loaded or 
updated). When such a keep-alive fails with a 401 code, the session has 
gone and the application terminates (so, the Admin is able to 
'disconnect' clients by invalidating their session). Currently, this 
happens for all active clients after reloading the context or restarting 
Tomcat :-(



That may be a security thing, but if, for example, passwords stored in
the GenericPrincipal instance are not serialized, I don't see a security
problem with persisting the session's principal.


User names and passwords are generally viewed as more sensitive that the
Principal object which is generally viewed as more sensitive than the
session ID.

Where users draw the line between what is acceptable and unacceptable is
going to vary.


I'm with you. And likely our setup is special in a way. However, I've 
rarely seen that you have to re-enter credentials in a professional web 
application like Google or Facebook, for example.


In some of our projects we use self-written replacements for Tomcat's 
GenericPrincipal (ours is serializable, I know yours in version 8 or 8.5 
is too, but on Ubuntu 14.04 we're still on Tomcat 7), StandardSession 
and StandardManager. However, it's some work to keep these classes up to 
date for new versions of Tomcat. So my basic question was, couldn't 
Tomcat do that for us?


I understand that different users have different requirements and for 
some, persisting a Principal (likely including a password) on disk for 
some seconds during a reload is really not acceptable. BTW, why ever do 
you save passwords??


So, the best solution to that would be to make this a configurable 
option of the Manager, named 'persistPrincipal', for example. Maybe I 
could even help developing that (if I had some time).





Do you have any ideas on that or do you know how to work around this?
Tomcat restarts are required from time to time. But it's really a bad
idea to kick out all currently logged-in users just because Tomcat needs
to be reconfigured, for example.


Re-entering credentials seems to be a major issue in this instance. Are
you able to share what is driving that (with more information we might
be able to identify a other solutions).

There are various 3rd-party session managers available for Tomcat. One
of those may well retain the Principal across restarts.


Yes, that may be true. And most if not all those frameworks are rather 
complex, feature-overloaded and can do everything for you (if you know how).


Actually, for our client applications, we use Tomcat only as a simple 
web server as well as for authentication and sessions. (Tomcat is also 
the container for GeoServer, which is part of most of our setups). So, a 
pure Tomcat solution would be my first choice.


Carsten

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

Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information

[Klein, Carsten]

Hi there,

in all recent Tomcat versions the standard session implementation 
declares authentication related fields as 'transient', so both the 
session's authType as well as it's authenticated Principal is not saved 
and restored across restarts.


On those fields there is a comment that clearly describes that:

/**
  * The authenticated Principal associated with this session, if any.
  * IMPLEMENTATION NOTE:  This object is not saved and
  * restored across session serializations!
  */
protected transient Principal principal = null;

However, the comment does not say WHY that information is omitted from 
serialization.


It's fine to have session data persisted across restarts, however, 
currently, a session is no longer authenticated after a restart (at 
least with form login, with which credentials are not sent with every 
request).


Actually, at least for my mind, that draws session persistence quite 
useless, because, after a restart, the client must re-login prior to use 
any resources having a security constraint.


That may be a security thing, but if, for example, passwords stored in 
the GenericPrincipal instance are not serialized, I don't see a security 
problem with persisting the session's principal.


Do you have any ideas on that or do you know how to work around this? 
Tomcat restarts are required from time to time. But it's really a bad 
idea to kick out all currently logged-in users just because Tomcat needs 
to be reconfigured, for example.


Regards Carsten

--

Carsten Klein
Lead Software Engineer

DataGis GmbH

Johann-Strauß-Str. 26
70794 Filderstadt

T +49 7158 9490-106
F +49 7158 9490-111

E-Mail: c.kl...@datagis.com
Internet: www.datagis.com

Registergericht: Amtsgericht Stuttgart, HRB 225945
Geschäftsführung: Dr. Gunter Hahn, Markus Ruess, Carsten Klein

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