-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Carsten,

> 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
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/

iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl3f144ACgkQHPApP6U8
pFgD2hAAkV25fJuasaBq+4ByaDWX6nhef228NhiErOiKhcAAyVUJIkxzcqMsCrtQ
BOxc60NF2zzLK/IxvSQv0xg13162jCK3EWhYSVH7nyj+KI8k6P1V4HALY8gWwTYy
ENGm2J906fBDXniGvKzeptfPb49wVAovbJ2JYZlCxnahTcfKOWI49KzaqR+bfgT8
tidKYmzGVYxn6mmS8fuFFW8xCwrLs3nJ0aK1qxuyjz9XBimkDGPAq/w0vviP2LCC
Pwuo8vJMNYdVqu4q5UMuszg1+QOGKIE+yX2ZOS+xWQ6L9rsc6Vy9EJ40vN5juNZP
AT8oajjJ5dtbPzUT8bDGrAaBtLLVEttIcuuHyi8wBa3hjy9y/BxJpTHDP5kpR/iJ
HTmibiNqEub/OI4NCS7WNiwrgsWrZhqECNPkZrzt1PA/qfCz4BS0UTJqs4kceCBu
/1LUc0BzNHkjY8gNaNlyymeerDQQm74TV0uiBqhZRpXp2UlyCXBM7SadWqMauht9
VxsnGv6k+VdDwlA/CRhpXh6Jcfi2k7SZy36yz2lZ+1U9qwiqCZMdzXBhyPcDIrmy
Vn/RB/0D/a2X+XrTlVZv6HceFeP62J8i4zRnjxC6NS4QgrDTnvmiQNDljrAaKwqu
/rfZdq3Ft9a1CKGWoV1dR4Dq/j8TH54Du7kbocQUHUFnN/lpYPE=
=7/bk
-----END PGP SIGNATURE-----

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

Reply via email to