tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rémy Maucherat <r...@apache.org>
Subject Re: JASPIC thoughts and a proposed way forward
Date Fri, 04 Dec 2015 21:33:57 GMT
2015-12-04 14:50 GMT+01:00 Mark Thomas <markt@apache.org>:

> On 04/12/2015 12:29, Rémy Maucherat wrote:
> > 2015-12-04 12:42 GMT+01:00 Mark Thomas <markt@apache.org>:
>
> >> The DIGEST module does not disable the default
> >> caching of the authenticated Principal in the session which renders the
> >> security benefits of digest over http largely useless.
> >
> > Apologies for missing it.
>
> No need to apologise. I missed it in the original commit and it wasn't
> until I started down the road of a new implementation and I could
> compare the two that I spotted it.
>
> > This one is problematic IMO since the Tomcat authenticator itself
> shouldn't
> > add implementation details about the module used. So fixing it would be a
> > hack. This is something you can think about for custom modules as well,
> > since there's no way to know if cache should be true or false [= cache
> > could have to default to false for JASPIC as a whole].
>
> The best I came up with was passing in an option to tell the module if
> an explicit caching option was set and using a callback to tell the
> authenticator valve to do the caching. It was all rather clunky.
>
> > As a side note, I would like to add DIGEST is going to be quite useless
> in
> > Tomcat 9 (assuming it was ever useful and used in the first place of
> > course). It could actually be proposed for removal, it is only a SHOULD
> in
> > the Servlet spec.
>
> You know me, always happy to remove obsolete / unnecessary code but what
> makes you say DIGEST is going to be useless in 9.0.x?
>

If it is hard to avoid using SSL with Tomcat 9, I don't see what use it
will have. Besides, I never saw any website using it.

>
> > IMO the focus of the GSoC turned out to be wrong: the project was about
> > redoing the Tomcat auth with JASPIC. The main priority should instead be
> > custom modules, and if it happens to work well, then bundle some modules
> > with Tomcat.
>
> +1. Never the less, the GSoC exercise was a useful learning experience
> despite the way it turned out. A fair amount of the new code should end
> up being re-used in some form.
>

Fair enough.

>
> >> This new JASPIC implementation would have the following aims:
> >> - follow ALL the requirements set out in JSR-196
> >> - enable web applications to configure JASPIC modules (both Tomcat
> >>   provided and 3rd party modules like [1]) without any additional
> >>   Tomcat configuration
> >
> > That's the important item.
>
> Agreed. That is where I want to start. See if I can integrate with one
> of the JASPIC-OAuth modules.
>
> >> If folks are find this approach agreeable, I'm currently planning to
> >> start on this towards the end of next week.
> >
> > Ok.
>
> Great.
>
> Rémy

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message