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
