You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Jean-Louis MONTEIRO <je...@gmail.com> on 2021/04/08 13:41:36 UTC

Re: Jakarta EE - JASPIC TCK (nightly)

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 <je...@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 <markt@apache.org
>> > <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 <markt@apache.org
>> >     <ma...@apache.org>
>> >     > <mailto:markt@apache.org <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-unsubscribe@tomcat.apache.org
>> >     <ma...@tomcat.apache.org>
>> >     >     <mailto:dev-unsubscribe@tomcat.apache.org
>> >     <ma...@tomcat.apache.org>>
>> >     >     For additional commands, e-mail: dev-help@tomcat.apache.org
>> >     <ma...@tomcat.apache.org>
>> >     >     <mailto:dev-help@tomcat.apache.org
>> >     <ma...@tomcat.apache.org>>
>> >     >
>> >     >
>> >     >
>> >     > --
>> >     > Jean-Louis
>> >
>> >
>> >
>>  ---------------------------------------------------------------------
>> >     To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> >     <ma...@tomcat.apache.org>
>> >     For additional commands, e-mail: dev-help@tomcat.apache.org
>> >     <ma...@tomcat.apache.org>
>> >
>> >
>> >
>> > --
>> > Jean-Louis
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>
> --
> Jean-Louis
>


-- 
Jean-Louis

Re: Jakarta EE - JASPIC TCK (nightly)

Posted by Mark Thomas <ma...@apache.org>.
On 08/04/2021 14:41, Jean-Louis MONTEIRO wrote:
> 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

Excellent! That is good news.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org