2015-12-04 14:50 GMT+01:00 Mark Thomas <ma...@apache.org>: > On 04/12/2015 12:29, Rémy Maucherat wrote: > > 2015-12-04 12:42 GMT+01:00 Mark Thomas <ma...@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
