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] - 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. 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 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 - 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. Mark [1] https://github.com/trajano/openid-connect [2] http://markmail.org/message/m6zq7scqaiw4eesf [3] http://markmail.org/message/wu2ckbkdb7d6sg2c [4] http://markmail.org/message/yppwgmfjedf3pk6d --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
