I believe the actual issue is related to the caching mechanism in CXF's updated
code. Due to this caching, the token validation now happens as soon as
getPrincipal() is called, which occurs much earlier in CXF 4.2.0 than in
previous versions.
As a result, our current TomEE code fails because at that point in the request
lifecycle, no Authorization header may be present (e.g., for @PermitAll
endpoints), and the token validation simply fails.
Additionally, I couldn't find clear guidance in the MP JWT specification
regarding the default behavior for non-annotated JAX-RS methods, i.e., methods
without @RolesAllowed, @PermitAll, or @DenyAll.
It appears this may be vendor-specific. Should the default be:
• @PermitAll (allow unauthenticated access)?
• @DenyAll (require authentication)?
• Something else?
Gruß
Richard
> Am 17.02.2026 um 14:54 schrieb Richard Zowalla <[email protected]>:
>
> Hi all,
>
> Due to a change in CXF 4.2.0 [1], specifically caching the principal instead
> of looking it up on demand, we are seeing several test failures in the MP JWT
> area - I am now wondering if this a thing CXF needs to address or if we need
> to update our integration. For this reason and after some debugging, I would
> like to get some additional context from the past regarding the architecture
> of our CXF/MP JWT integration :)
>
> The failure in question can be reproduced by running
> OrderTest#shouldBeRunning() from the main branch in
> examples/mp-rest-jwt-principal, or by executing parts of the MP JWT TCK,
> which are also failing.
>
> The test calls an endpoint that, according to the test assumptions, shouldn’t
> be protected. It passes on TomEE 10 / CXF 4.1.5 (which does not cache the
> principal). The relevant code on our side is mainly in MPJWTFilter,
> especially the MPJWTServletRequestWrapper and its use of validate(…).
>
> Since I’m not an active MP JWT user, I have some (maybe dumb?) questions:
>
> According to [2], an application annotated with @LoginConfig(authMethod =
> "MP-JWT") requires MP-JWT Access Control (potentially for all endpoints?).
>
> If that is the case, the status() method of OrderRestin
> https://github.com/apache/tomee/blob/main/examples/mp-rest-jwt-principal/src/main/java/org/superbiz/store/rest/OrderRest.java
> should require a JWT, no?
>
> However, we don’t add a token to the REST client in
> https://github.com/apache/tomee/blob/main/examples/mp-rest-jwt-principal/src/test/java/org/superbiz/store/OrderRestClient.java#L35,
> so the request is sent without a bearer token and fails with a 401.
>
> This worked on TomEE 10 / CXF 4.1.5 and earlier.
>
> I suspect some MP JWT TCK failures are caused by the same issue. See the
> build here:
> https://ci-builds.apache.org/job/TomEe/job/master-build-full/org.apache.tomee$microprofile-jwt-tck/2071/
>
> Question:
>
> What is the expected behavior? From my reading of the spec, it seems this
> endpoint shouldn’t be invocable without a valid token?
>
> Could anyone with more experience in this area (David, JL, anyone?) provide
> some insight?
>
> Thanks and Gruß
> Richard
>
> [1]
> https://github.com/apache/cxf/pull/2807/changes#diff-eddf423fac99200bd14e115467dc35809e1855cefdf3bae77f9394b8c050fc94L419
> [2]
> https://download.eclipse.org/microprofile/microprofile-jwt-auth-2.1/microprofile-jwt-auth-spec-2.1.html#_marking_a_jax_rs_application_as_requiring_mp_jwt_access_control
>
