Le lun. 26 avr. 2021 à 18:57, Mark Thomas <ma...@apache.org> a écrit :
> On 26/04/2021 17:38, Romain Manni-Bucau wrote: > > JAASRealm is quite commonly used whereas JASPIC is almost never used > > References? > Sadly not public but all project not using a custom valve/auth where using jaas and some good part of it (Id say 35%) sharing a login module. > In my trawl of the Tomcat archives those using the JAAS realm appeared > to have better solutions available whereas those using JASPIC were doing > so for the "right" reasons. > > If there is evidence that the JAAS realm is meeting a user need I'd like > to see it (and understand why JAAS is a better solution than the > alternatives). > Mainly cause it has impl and shareable modules between apps (karaf, tomcat, standalone) whereas jaspic is not. At least being able to enable jaas is important I'd say cause it reduces cost compare to jaspic dev which must be redone for other env (not spread enough). > Mark > > > > (and > > not even speaking of Jakarta Security which has no link with two previous > > ones). > > Main difference is the fact JAAS is in the JVM (with some impl like OS > one > > which is not always trivial to do portably) whereas two others are not so > > it means you easily find a JAAS login module implementation and you don't > > find integrations for others so think it makes sense to keep JAAS > > integration more than others in default delivery. > > > > Romain Manni-Bucau > > @rmannibucau <https://twitter.com/rmannibucau> | Blog > > <https://rmannibucau.metawerx.net/> | Old Blog > > <http://rmannibucau.wordpress.com> | Github < > https://github.com/rmannibucau> | > > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > Le lun. 26 avr. 2021 à 18:31, Filip Hanik <fi...@hanik.com> a écrit : > > > >> On Mon, Apr 26, 2021 at 09:17 Mark Thomas <ma...@apache.org> wrote: > >> > >>> In reviewing references to Java EE (and J2EE) remaining in the Tomcat > 10 > >>> repo I found the following: > >>> > >>> <quote source="webapps/docs/config/realm.xml"> > >>> JAASRealm is prototype for Tomcat of the JAAS-based J2EE authentication > >>> framework for J2EE v1.4, based on the <a > >>> href="https://www.jcp.org/en/jsr/detail?id=196";>JCP Specification > >>> Request 196</a> to enhance container-managed security and promote > >>> 'pluggable' authentication mechanisms whose implementations would be > >>> container-independent. > >>> </quote> > >>> > >>> JSR became JASPIC (now Jakarta Security) and Tomcat has an > >> implementation. > >>> > >>> Searching through the mailing lists I found the following references to > >>> usage of the JAASRealm (going back ~5 years). > >>> > >>> [1] Tomcat 7 user using JAAS based auth to an LDAP server > >>> [2] Tomcat 9 user using SPNEGO with the JAAS realm > >>> [3] Tomcat 8.5 user using SPNEGO with the JAAS realm > >>> [4] Tomcat 7 users with custom CLIENT-CERT auth based on JAAS realm > >>> [5] User wanting access to HttpServletRequest during auth > >>> > >>> Most, if not all, of those have better solutions available than the > JAAS > >>> Realm. And those wanting some form of custom auth do have the "proper" > >>> Jakarta Security API to work with. > >>> > >>> Therefore, I'm not currently seeing a good reason to keep the > JAASRealm. > >>> Any objections to immediate deprecation with removal planned for > 10.1.x? > >> > >> > >> No objections, > >> go for it > >> > >> > >>> > >>> Mark > >>> > >>> > >>> [1] http://markmail.org/message/ndvr5ilxovoo4ins > >>> [2] http://markmail.org/message/5ocdnmqvvlvjsxas > >>> [3] http://markmail.org/message/wki275i5yhlg3yyo > >>> [4] http://markmail.org/message/av2sv6g4kgm6ouu4 > >>> [5] http://markmail.org/message/fm4ggo3ge4r47gar > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > >>> For additional commands, e-mail: dev-h...@tomcat.apache.org > >>> > >>> > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
