Hash: SHA256


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

What's interesting is that GenericPrincipal, the only concrete
Principal class provided by Tomcat, does not have transient fields for
username and password. And, oddly, when serialized, a
SerializablePrincipal object is swapped-out in its place.

Seems strange to me. The SerializablePrincipal is private static to
it's not intended to be an extension point for user code.

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

But they *would* be serialized along with the Principal object if no
changes were made to the SerializedPrincipal class. Since it's
private, it could be changed.

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

I'm not sure why Tomcat needs to store the Principal's password (and I
haven't checked to see if FormAuthenticator sets this value to the
user's password, or null instead which would be way better), but
serializing that to the disk would be Bad. There isn't any encryption
being placed on those stored files which means that serializing them
would be a security issue.

Honestly, I think it's reasonable to (a) not store the password and
(b) serialize the Principal, but it's not as simple as just "remove
transient from the member declaration".

I've been using another authentication mechanism for so long, I didn't
realize that Tomcat worked this way. The same seems to be true for
clustered sessions -- you have to re-login if you fail-over to another
node in the cluster.

That seems pretty inconvenient. If this could be configurable, it
might be very nice to have, especially for the clustering use-case.

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


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

Reply via email to