tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information
Date Thu, 28 Nov 2019 09:20:39 GMT
On 28/11/2019 08:03, Klein, Carsten wrote:
> 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.

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

> On those fields there is a comment that clearly describes that:
> /**
>   * The authenticated Principal associated with this session, if any.
>   * <b>IMPLEMENTATION NOTE:</b>  This object is <i>not</i>
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?

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

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


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message