[
https://issues.apache.org/jira/browse/TOMEE-4648?focusedWorklogId=1031929&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-1031929
]
ASF GitHub Bot logged work on TOMEE-4648:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 23/Jul/26 19:34
Start Date: 23/Jul/26 19:34
Worklog Time Spent: 10m
Work Description: jungm opened a new pull request, #2851:
URL: https://github.com/apache/tomee/pull/2851
## What
Fixes [TOMEE-4648](https://issues.apache.org/jira/browse/TOMEE-4648): the
BASIC authentication mechanism answered `401` for valid credentials when
validation went against an application-supplied `IdentityStore`.
## Why
`BasicAuthenticationMechanism` passed a `BasicAuthenticationCredential` to
`IdentityStoreHandler.validate(Credential)`. The spec's default
`IdentityStore.validate(Credential)` dispatches to a `validate(...)` overload
**only on an exact parameter-type match** — its javadoc states explicitly that
it does not look for the most specific overload. Since
`BasicAuthenticationCredential extends UsernamePasswordCredential`, a store
declaring the idiomatic `validate(UsernamePasswordCredential)` overload
(exactly what the Jakarta Security TCK's `TestIdentityStore` does) was never
invoked and returned `NOT_VALIDATED`, producing a 401.
Built-in stores (e.g. Tomcat users) declare their own credential handling
and were unaffected, which is why this only surfaced with an application store
— and why the plain, decorated, and custom-handler TCK variants all failed the
same `testAuthenticated` check.
## Change
`BasicAuthenticationMechanism.validateRequest` still parses the
`Authorization` header via `BasicAuthenticationCredential` (which does the
base64 decoding), but now hands the identity store a plain
`UsernamePasswordCredential`, reusing the already-parsed `Password` (no
plaintext round-trip). The empty/malformed-header path is unchanged — the
constructor still throws `IllegalArgumentException`, caught as before to fall
through to the challenge.
## Tests
- New `Tomee4648BasicGroupsTest` mirrors the TCK `app-mem-basic` module (an
`@ApplicationScoped IdentityStore` with only the
`validate(UsernamePasswordCredential)` overload). It fails with 401 before the
change and passes after, asserting caller name and both groups.
- Full `tomee-security` module is green (108 tests), including the existing
BASIC negative cases (wrong password, unknown user, missing role).
## TCK impact
Removes the cause of these exclusions in the apache/tomee-tck `security`
runner:
- `AppMemBasicIT#testAuthenticated`
- `AppMemBasicDecorateIT#testAuthenticated`
- `AppCustomAuthenticationMechanismHandler2IT`
## Note for reviewers
The two OpenID TCK modules originally bundled into TOMEE-4648 were **not** a
TomEE bug — they were a test-harness environment issue (the bundled OpenID
provider's `startup.sh` needs `JAVA_HOME`, which was unset). Both pass
unchanged once `JAVA_HOME` is set; that fix lives in apache/tomee-tck and is
out of scope for this PR. The ticket has been updated accordingly.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Issue Time Tracking
-------------------
Worklog Id: (was: 1031929)
Remaining Estimate: 0h
Time Spent: 10m
> Jakarta Security: BASIC mechanism rejects valid credentials with an
> application IdentityStore
> ---------------------------------------------------------------------------------------------
>
> Key: TOMEE-4648
> URL: https://issues.apache.org/jira/browse/TOMEE-4648
> Project: TomEE
> Issue Type: Bug
> Reporter: Markus Jung
> Assignee: Markus Jung
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When the BASIC authentication mechanism validates credentials against an
> application-supplied {{IdentityStore}}, TomEE answers 401 even when the
> caller sends valid credentials. This shows up in the plain BASIC test and in
> the decorated and custom-handler variants
> ({{AppCustomAuthenticationMechanismHandler2IT}}), so the problem is not about
> wrapping the mechanism.
> h2. Root cause
> The BASIC mechanism passed a {{BasicAuthenticationCredential}} to
> {{IdentityStoreHandler.validate(Credential)}}. The spec's default
> {{IdentityStore.validate(Credential)}} dispatches to a {{validate(...)}}
> overload only on an _exact_ parameter-type match (its javadoc explicitly
> states it does not look for the most specific overload). Because
> {{BasicAuthenticationCredential extends UsernamePasswordCredential}}, a store
> declaring the idiomatic {{validate(UsernamePasswordCredential)}} overload —
> exactly what the TCK's {{TestIdentityStore}} does — was never invoked and
> returned {{NOT_VALIDATED}}, producing a 401 for correct credentials. Built-in
> stores (e.g. Tomcat users) were unaffected, which is why it only surfaced
> with an application store.
> Fix: the BASIC mechanism now hands the identity store a plain
> {{UsernamePasswordCredential}} while still parsing the header via
> {{BasicAuthenticationCredential}}.
> h2. Steps to reproduce / TCK reference
> Run the Jakarta Security 4.0 TCK reactor against TomEE Plus (Java 21) through
> the {{security}} runner in {{runner-standalone}}. The following tests fail
> and are excluded in {{runner-standalone/exclusions/security.txt}} in the
> apache/tomee-tck harness repo:
> * {{AppCustomAuthenticationMechanismHandler2IT}} (3 failing methods)
> * {{AppMemBasicDecorateIT#testAuthenticated}}
> * {{AppMemBasicIT#testAuthenticated}}
> Remove the matching lines from {{security.txt}} once fixed, then re-run the
> {{security}} runner to confirm all three test classes pass.
> h2. Note on the OpenID modules (not a TomEE bug)
> {{OpenId2DefaultIT}} and {{OpenId3DefaultIT}} were previously listed here as
> token-validation failures. Investigation showed this was a test-harness
> environment problem, not a TomEE defect: these modules start their bundled
> OpenID provider through Tomcat's {{startup.sh}}, which requires
> {{JAVA_HOME}}/{{JRE_HOME}} and ignores {{PATH}}. With those unset the
> provider never started, the client's {{.well-known}} discovery fetch was
> refused, and the tests failed downstream in a way that looked like a token
> check. With {{JAVA_HOME}} set, both OpenID modules pass unchanged. The runner
> has been fixed in apache/tomee-tck to derive {{JAVA_HOME}} when unset; the
> two OpenID entries can be dropped from {{security.txt}} once a corrected CI
> run confirms them.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
