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