Thinking out loud: can't it become a jaspic jaas impl delivered on central (this point is crucial), can be tomcat-jaas or so but not bundled by default in the distribution? Jaspic enables to do from the app so it becomes an option it seems which enables the use case so limit a lot the required "glue" to compensate a drop or is it still "too much" to maintain in your opinion?
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 à 21:46, Jean-Louis MONTEIRO <jeano...@gmail.com> a écrit : > Le lun. 26 avr. 2021 à 20:48, Mark Thomas <ma...@apache.org> a écrit : > > > On 26/04/2021 18:49, Jean-Louis MONTEIRO wrote: > > > JAAS, JASPIC and Jakarta Security are all different. > > > > My mistake. I knew JASPIC had a slightly bigger rename than most specs > > and incorrectly thought it became Jakarta Security. It actually became > > Jakarta Authentication. All previous references from me in this thread > > to "Jakarta Security" should be read as "Jakarta Authentication". > > > > No problem. > > > > > > > Tomcat does not implement Jakarta Security so removing JAAS creates a > gap > > > in my opinion. > > > > > > I'd second Romain, JASPIC requires a SAM to be implemented by the > > > application. > > > > > > Long story short, I'd probably deprecate for 10.x and target a removal > > for > > > 11.x > > > > In the normal course of things 10.1 would have been 11.0 but we are > > taking the opportunity align Jakarta EE major version and Tomcat major > > version as well as have a (much) shorter support lifespan for 10.0 > > (Jakarta EE 9) as that is seen as a transitional release. > > > > Tomcat 10.1 will implement the usual subset of specs from Jakarta EE 10. > > > > Sorry I missed that information. > So it appeared to be a bit too aggressive to deprecate and remove. > > > > > > Mark > > > > > > > Le lun. 26 avr. 2021 à 18:17, Mark Thomas <ma...@apache.org> a écrit : > > > > > >> 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? > > >> > > >> 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 > > > > > > -- > Jean-Louis >
