Small update ... I sent some PRs
https://github.com/eclipse-ee4j/jakartaee-tck/pull/706 https://github.com/eclipse-ee4j/jakartaee-tck/pull/707 When this gets merged, we are 100% coverage. Tomcat 10.x JASPIC implementation is Jakarta EE 9.1 compatible Le jeu. 12 nov. 2020 à 19:30, Jean-Louis MONTEIRO <jeano...@gmail.com> a écrit : > Hi, > > Bumping this thread up. Sorry for the late reply. Been very busy getting > Jakarta EE 9 out. Ballot if open till next Friday, so back into this issue. > > I created 2 tickets regarding JASPIC and I need to open another one for > the issue discussed in this thread. > > https://github.com/eclipse-ee4j/jakartaee-tck/issues/570 > https://github.com/eclipse-ee4j/jakartaee-tck/issues/571 > > I agree we need to clarify this part, as it looks most likely like a TCK > bug. > Anyway, thanks for the thoughts. > > > Le jeu. 23 juil. 2020 à 16:18, Mark Thomas <ma...@apache.org> a écrit : > >> Comments in line. >> >> On 22/07/2020 10:19, Jean-Louis MONTEIRO wrote: >> > Hi, >> > >> > Small update on the progress. >> > Passed: 52 and Failed: 9 >> > >> > I had a lot of random passed/failed for quite a while and finally found >> > the reason yesterday. >> >> I took a look at running these myself for Tomcat. There is a lot of >> fiddly setup required. I may come back to this but for now I have other >> priorities. >> >> > I'd be interested in having some thoughts >> > >> > AuthenticatorBase uses by default CallbackHandlerImpl >> > >> > The CallbackHandlerImpl will create the GenericPrincipal for the subject >> > based on the supported callbacks (CallerPrincipalCallback >> > and GroupPrincipalCallback). >> > >> > The AuthenticatorBase will pull the GenericPrincipal from the subject >> > and do the register. >> > >> > Long story short, the TCK calls the CallbackHandlerImpl twice with the >> > CallerCallback and another time with CallerCallback + GroupCallback. We >> > end up having 2 GenericPrincipal in the subject, one with the name only >> > and another one with the name and roles. >> > >> > JASPIC >> > TCK >> https://github.com/eclipse-ee4j/jakartaee-tck/blob/master/src/com/sun/ts/tests/jaspic/tssv/module/servlet/TSServerAuthModule.java#L371 >> > >> > See >> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/jaspic/CallbackHandlerImpl.java#L96 >> > >> > Issue is that AuthenticatorBase pulls the first one available. >> > See >> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina/authenticator/AuthenticatorBase.java#L956 >> > >> > It will randomly pull the GenericPrincipal with the name only or the >> > GenericPrincipal with the name and the roles. >> >> Nice find. That must have been a real pain to track down. >> >> I've been reading through the Jakarta Authentication specification (it >> should be essentially identical to the previous JASPIC spec). >> >> From 3.8.3.1 >> <quote> >> ... handle a CallerPrincipalCallback using the clientSubject as argument >> to the callback. If more than one module of a context uses the >> CallbackHandler to handle this callback, the context is responsible for >> coordinating the calls such that the appropriate caller principal value >> is established. >> </quote> >> >> context here is referring to ServerAuthContext. >> >> I think, in this case, the ServerAuthContext is being provided by the >> TCK so my first impression is that this is a TCK bug. >> >> I think this is worth raising on the Jakarta Authentication mailing lists. >> >> > I did a fork in TomEE of the CallbackHandlerImpl to merge the >> > GenericPrincipal in the name is the same and switched the >> > CallbackHandlerImpl class in the BasicAuthenticator valve. >> >> Yes, that is the same solution I thought of. Rather than add the newly >> created GenericPrincipal to the Subject's private credentials, see if >> the new GenericPrincipal has the same name as an existing >> GenericPrincipal and if it does merge them. >> >> I'm not sure that would be safe to do in the general case though. >> >> Mark >> >> >> > >> > Hope it's more or less clear ;-) >> > Some thoughts would be very helpfup >> > >> > >> > Le ven. 17 juil. 2020 à 18:21, Mark Thomas <ma...@apache.org >> > <mailto:ma...@apache.org>> a écrit : >> > >> > On 17/07/2020 16:56, Jean-Louis MONTEIRO wrote: >> > > Hi, >> > > >> > > Following up on this thread. >> > > Pretty old I know. Haven't seen more recent topics on JASPIC and >> > Jakarta >> > > EE TCK. >> > > >> > > I tried to invest some time in TomEE to run the JASPIC TCK which >> is >> > > fully relying on Tomcat. >> > > I have counted 68 tests under the package com.sun.ts.tests.jaspic >> > > >> > > The wiki says 100+ so dunno where I'm missing some. >> > > >> > > Long story short, after some time configuring the thing, I've got >> > > >> > > Passed: 38 >> > > Failed: 30 >> > > >> > > Anyone looked at it already since Feb 2019? >> > >> > I'm probably the most likely candidate and I haven't looked at it. >> > >> > Mark >> > >> > >> > > >> > > >> > > Le lun. 11 févr. 2019 à 21:34, Mark Thomas <ma...@apache.org >> > <mailto:ma...@apache.org> >> > > <mailto:ma...@apache.org <mailto:ma...@apache.org>>> a écrit : >> > > >> > > All, >> > > >> > > I've started to look at the Jakarta EE JASPIC TCK. >> > > >> > > Again a nightly build so usual caveats apply. >> > > >> > > Progress is being tracked here: >> > > https://cwiki.apache.org/confluence/display/TOMCAT/JASPIC+TCK >> > > >> > > Hmm. >> > > >> > > This TCK seems very different to the standalone TCKs for the >> > other specs >> > > we implement. >> > > - Deployment is significantly more complex. Rather than just >> > WARs there >> > > are some JARS that need to be extracted and rename from >> EARs. >> > > - It seems to need the RI up and running for the tests. >> > > >> > > >> > > I'm giving up on this for now. I may come back to it at some >> > point but I >> > > think it is more likely that I won't. >> > > >> > > Mark >> > > >> > > >> > >> --------------------------------------------------------------------- >> > > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> > <mailto:dev-unsubscr...@tomcat.apache.org> >> > > <mailto:dev-unsubscr...@tomcat.apache.org >> > <mailto:dev-unsubscr...@tomcat.apache.org>> >> > > For additional commands, e-mail: dev-h...@tomcat.apache.org >> > <mailto:dev-h...@tomcat.apache.org> >> > > <mailto:dev-h...@tomcat.apache.org >> > <mailto:dev-h...@tomcat.apache.org>> >> > > >> > > >> > > >> > > -- >> > > Jean-Louis >> > >> > >> > >> --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> > <mailto:dev-unsubscr...@tomcat.apache.org> >> > For additional commands, e-mail: dev-h...@tomcat.apache.org >> > <mailto:dev-h...@tomcat.apache.org> >> > >> > >> > >> > -- >> > Jean-Louis >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> >> > > -- > Jean-Louis > -- Jean-Louis
