Jakarta EE - JASPIC TCK (nightly)

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Jakarta EE - JASPIC TCK (nightly)

Mark Thomas-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE - JASPIC TCK (nightly)

Jean-Louis MONTEIRO
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?


Le lun. 11 févr. 2019 à 21:34, Mark Thomas <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]



--
Jean-Louis
Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE - JASPIC TCK (nightly)

Mark Thomas-2
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 <[hidden email]
> <mailto:[hidden email]>> 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: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>
>
> --
> Jean-Louis


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE - JASPIC TCK (nightly)

Jean-Louis MONTEIRO
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'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.




It will randomly pull the GenericPrincipal with the name only or the GenericPrincipal with the name and the roles.

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.

Hope it's more or less clear ;-)
Some thoughts would be very helpfup


Le ven. 17 juil. 2020 à 18:21, Mark Thomas <[hidden email]> 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 <[hidden email]
> <mailto:[hidden email]>> 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: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>
>
> --
> Jean-Louis


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]



--
Jean-Louis
Reply | Threaded
Open this post in threaded view
|

Re: Jakarta EE - JASPIC TCK (nightly)

Mark Thomas-2
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 <[hidden email]
> <mailto:[hidden email]>> 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 <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> 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: [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     >     <mailto:[hidden email]
>     <mailto:[hidden email]>>
>     >
>     >
>     >
>     > --
>     > Jean-Louis
>
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: [hidden email]
>     <mailto:[hidden email]>
>     For additional commands, e-mail: [hidden email]
>     <mailto:[hidden email]>
>
>
>
> --
> Jean-Louis


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]