This is an automated email from the ASF dual-hosted git repository.
coheigea pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/ws-wss4j.git
The following commit(s) were added to refs/heads/master by this push:
new a8fb5fe7a Better document REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS
a8fb5fe7a is described below
commit a8fb5fe7a830c9606cabc04b1f1e743dc73f53cc
Author: Colm O hEigeartaigh <[email protected]>
AuthorDate: Mon Sep 21 09:10:57 2026 +0100
Better document REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS
---
THREAT-MODEL.md | 14 ++++++++++++++
src/site/asciidoc/config.adoc | 6 ++++--
src/site/asciidoc/streaming.adoc | 10 ++++++++++
3 files changed, 28 insertions(+), 2 deletions(-)
diff --git a/THREAT-MODEL.md b/THREAT-MODEL.md
index 8325d177f..5852447bf 100644
--- a/THREAT-MODEL.md
+++ b/THREAT-MODEL.md
@@ -597,6 +597,20 @@ matching disclaimer.
enforce security requirements")*. The action-based API requires the
caller to specify which parts must be signed; failing to specify them
produces a working but insecure deployment.
+- **No `REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS` enforcement in the
+ streaming engine.** The tag is defined in the shared
+ `ConfigurationConstants` and read only by the DOM processors
+ (`EncryptedDataProcessor`, `ReferenceListProcessor`,
+ `EncryptedKeyProcessor`). The StAX `ConfigurationConverter` takes only
+ the tags it implements and silently ignores the rest, so a streaming
+ endpoint that sets it is not protected and is not told. The streaming
+ documentation states that the two stacks are "configured in mostly the
+ same way (via configuration tags that are shared between both
+ stacks)", which makes this an easy loss on migration. → documented as
+ a limitation in `src/site/asciidoc/streaming.adoc` and marked DOM-only
+ in `src/site/asciidoc/config.adoc`; a report of it is
+ `VALID-HARDENING` against the streaming engine, not a silent-failure
+ bug in the DOM one.
- **No defense against an authenticated peer who is *also* authorized
to do the operation.** WSS4J authenticates the peer and validates the
signature; whether the peer is allowed to do what the SOAP body says
diff --git a/src/site/asciidoc/config.adoc b/src/site/asciidoc/config.adoc
index 210dfb337..a35af6f39 100644
--- a/src/site/asciidoc/config.adoc
+++ b/src/site/asciidoc/config.adoc
@@ -195,8 +195,10 @@ is "false".
"false".
* *WSS4J 2.0.0* ALLOW_USERNAMETOKEN_NOPASSWORD (allowUsernameTokenNoPassword)
- Whether a UsernameToken with no password element is allowed. Default is
"false".
- * REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS (requireSignedEncryptedDataElements)
- Whether the engine needs to enforce EncryptedData elements are in a signed
-subtree of the document. Default is "false".
+ * *DOM only* REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS
(requireSignedEncryptedDataElements) - Whether the engine needs to enforce
EncryptedData elements are in a signed
+subtree of the document. Default is "false". The streaming (StAX) code does not
+read this tag and does not enforce it - see the limitations in the streaming
+documentation.
* *WSS4J 1.6.x only* USE_DERIVED_KEY (useDerivedKey) - Whether to use the
standard UsernameToken Key Derivation algorithm.
Default is "true".
* ALLOW_NAMESPACE_QUALIFIED_PASSWORD_TYPES
(allowNamespaceQualifiedPasswordTypes) - Whether (wsse) namespace qualified
password types are accepted when
diff --git a/src/site/asciidoc/streaming.adoc b/src/site/asciidoc/streaming.adoc
index 1c73eb94c..3d5484c85 100644
--- a/src/site/asciidoc/streaming.adoc
+++ b/src/site/asciidoc/streaming.adoc
@@ -87,4 +87,14 @@ nothing on its own. Check the effective policy if you rely
on a nested
assertion being enforced.
* Where a compact policy offers several alternatives within a nested policy,
only the first is read.
+ * The REQUIRE_SIGNED_ENCRYPTED_DATA_ELEMENTS
("requireSignedEncryptedDataElements")
+configuration tag is not read by the streaming code and is not enforced by it.
+The tag is shared between both stacks, and the streaming ConfigurationConverter
+takes only the tags it implements, so setting it on a streaming endpoint has no
+effect and reports nothing. A deployment that switches from the DOM
interceptors
+to the streaming ones therefore loses the requirement that every EncryptedData
+element sits in a signed subtree. Use WS-SecurityPolicy SignedParts and
+EncryptedParts to state what must be signed and encrypted, and note that they
+constrain the parts the policy names rather than forbidding an additional
+EncryptedData elsewhere in the message.
