2015-12-04 12:42 GMT+01:00 Mark Thomas <ma...@apache.org>: > I've been spending some time looking at the JASPIC implementation that > was started as part of GSoC. > > To recap the history to save folks digging through the archives: > > - JASPIC provides a standard API for pluggable authentication modules > > - The most obvious use case is integration with one of the many > JASPIC-OAUTH module, e.g. [1] > > - A JASPIC implementation was started under GSoC earlier this year but > the project failed after the student disappeared after the mid-term > evaluation. [2] > > - The student returned later promising to finish the work but that too > came to nothing. [3] >
Yes ! Me not happy :( > > - The aim of the GSoC project was to provide a JASPIC implementation > and port the various authentication mechanisms (BASIC, SPNEGO, etc) > to JASPIC modules. > > During my review, I have confirmed that the security concerns I > expressed in [2] were well founded. So far, I have only found one issue > but that is one too many. 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. I remain > concerned that the unnecessary refactoring of the authentication code > may have introduced further issues. > Apologies for missing 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]. 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. > > While reviewing the current implementation, I have also identified > additional concerns: > > - The implementation is extremely hard to follow. Part of that is due > to the nature of the JASPIC API but part of it is down to the > implementation and is caused by a combination of factors including > unclear naming and excessive decomposition - to the detriment of > clarity and performance > - Quite a few details of the JASPIC requirements have been glossed over > 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. > > Remy has expressed a general concern [4] regarding complexity and speed. > > Currently, I share Remy's general concerns although I do wonder how much > of the current complexity is due to JASPIC and how much is the > implementation. > > While the current implementation does have issues, I have found it to be > a useful reference when examining alternative approaches so I do not > want to just delete it. > > Given all of the above, I would like to propose the following way forward: > > - Create a new jaspic-gsoc branch from the current trunk > - Remove o.a.c.authenticator.jaspic from trunk and associated tests, > references, etc > - Review the javax.security.auth.message.* implementation and > address any issues found > - Start a new o.a.c.authenticator.jaspic implementation using the > jaspic-gsoc branch as a reference. Use a combination of copying > and re-writing as appropriate. > > 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. > - explore re-implementing the current authentication mechanisms > using JASPIC > - only replace the current authentication mechanisms with the > JASPIC alternative if the performance of the JASPIC module is > comparable > > If folks are find this approach agreeable, I'm currently planning to > start on this towards the end of next week. > > Ok. Rémy
