Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information

[Mark Thomas <ma...@apache.org>]

On 29/11/2019 11:48, Klein, Carsten wrote:

<snip/>

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

Yes. But if those apps were running on Tomcat I doubt that a) they'd be
running on a single instance and b) they'd be using Tomcat's in memory
session management.

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

As an option, disabled by default I don't see why not.

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

Good question. I suspect it might be related to single-sign-on but I'd
need to do some svn archaeology to try and answer that more definitively.

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

Agreed.

A good place to start would be to open a Bugzilla enhancement request
against 9.0.x (we always develop for the latest version first and then
back-port).

After that, we accept patches in Bugzilla or Pull Requests at GitHub.
Expect a fair amount a feedback on your first version (my first patch
needed to be completely re-written) but a couple of tips to reduce the
rework:
- enable checkstyle and make sure there are no errors when building
- generally, follow the style of the code you are editing (the Tomcat
  code style is not always consistent)

Mark

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

Re: Tomcat 7.x.x, 8.x.x, 8.5.x and 9.x.x: Session serialization w/o authentication related information

[Carsten Klein <c....@datagis.com>]

On 01/12/2019 23:04, Mark Thomas wrote:

<snip/>

>> 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.
> 
> Yes. But if those apps were running on Tomcat I doubt that a) they'd be
> running on a single instance and b) they'd be using Tomcat's in memory
> session management.
> 
Yes, my comparison was not really fair. Just wanted to point out, that 
re-entering credentials is no longer common in today's applications.

> As an option, disabled by default I don't see why not.

<snap/>

> Agreed.
> 
> A good place to start would be to open a Bugzilla enhancement request
> against 9.0.x (we always develop for the latest version first and then
> back-port).

Makes sense.

> After that, we accept patches in Bugzilla or Pull Requests at GitHub.
> Expect a fair amount a feedback on your first version (my first patch
> needed to be completely re-written) but a couple of tips to reduce the
> rework:
> - enable checkstyle and make sure there are no errors when building
> - generally, follow the style of the code you are editing (the Tomcat
>    code style is not always consistent)

So, I will give that a try. Hope to come up with a patch within the next 
couple of weeks. The patch itself seems not to be too challenging.

Thanks for your advice and tips.

Carsten

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