This is an automated email from the ASF dual-hosted git repository. coheigea pushed a commit to branch coheigea/bst-docs in repository https://gitbox.apache.org/repos/asf/ws-wss4j.git
commit 6eac79c044e2fcd91963bbe5491a78adfda8ab0b Author: Colm O hEigeartaigh <[email protected]> AuthorDate: Fri Sep 18 10:36:04 2026 +0100 Adding docs about trust credentials for BST --- THREAT-MODEL.md | 17 +++++++++++++++++ .../java/org/apache/wss4j/dom/engine/WSSConfig.java | 9 +++++++++ 2 files changed, 26 insertions(+) diff --git a/THREAT-MODEL.md b/THREAT-MODEL.md index 957498a9d..7efb50d5e 100644 --- a/THREAT-MODEL.md +++ b/THREAT-MODEL.md @@ -711,6 +711,23 @@ The embedding SOAP stack / application **must**: - **Mixing the action-based and WS-SecurityPolicy approaches in the same handler chain.** The behavior across both is documented but rarely tested. +- **Registering a `Validator` for `WSConstants.BINARY_TOKEN` in order to + inspect or transform a BinarySecurityToken.** Registering *any* + Validator for that QName marks the token as validated, and + `SignatureSTRParser` then treats a Signature referencing that token as + a trusted credential, so the Signature Validator + (`SignatureTrustValidator` by default) never runs for it — a + certificate the truststore does not trust is accepted. This is + long-standing intentional behaviour, and is how Kerberos and other + opaque BinarySecurityTokens obtain their direct trust + *(`ValidatorTest.testValidatedBSTSignature` pins it)*. The trap is that + a Validator registered for an unrelated purpose — or a + `NoOpValidator` — disables signature trust verification just as + effectively, with nothing to signal it. Register a Validator for this + QName only if it verifies the token itself, or accept that signatures + referencing that token are not trust-checked. No BinarySecurityToken + Validator is registered by default, so the default configuration is + unaffected *(documented: `WSSConfig.setValidator` javadoc)*. - **Reading a `SIGN` result as proof of sender identity without looking at what keyed it.** With the action-based approach, `action="Signature Encrypt"` is satisfied by a signature keyed from an inbound diff --git a/ws-security-dom/src/main/java/org/apache/wss4j/dom/engine/WSSConfig.java b/ws-security-dom/src/main/java/org/apache/wss4j/dom/engine/WSSConfig.java index 9257ae739..733c99eff 100644 --- a/ws-security-dom/src/main/java/org/apache/wss4j/dom/engine/WSSConfig.java +++ b/ws-security-dom/src/main/java/org/apache/wss4j/dom/engine/WSSConfig.java @@ -476,6 +476,15 @@ public final class WSSConfig { * * Please note that the Validator object does NOT get class-loaded per invocation, and so * it is up to the implementing class to ensure that it is thread-safe. + * + * Note for WSConstants.BINARY_TOKEN: registering any Validator for this QName - including + * one registered only to inspect or transform the token, or a NoOpValidator - marks the + * token as validated, and a Signature referencing that token is then treated as a trusted + * credential, so the Signature Validator (SignatureTrustValidator by default) does not + * run for it. This is how Kerberos and other opaque BinarySecurityTokens obtain direct + * trust, but it applies equally to a Validator that verifies nothing. Register a Validator + * here only if it verifies the token itself, or accept that signatures referencing that + * token are not trust-checked. */ public Class<?> setValidator(QName el, Validator validator) { Object result = validatorMap.put(el, validator);
