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