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 bb75f5a85 Docs update
bb75f5a85 is described below
commit bb75f5a856ee812aaa0fa5f8719525a430c75bc1
Author: Colm O hEigeartaigh <[email protected]>
AuthorDate: Thu Sep 10 14:49:48 2026 +0100
Docs update
---
src/site/asciidoc/best_practice.adoc | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/src/site/asciidoc/best_practice.adoc
b/src/site/asciidoc/best_practice.adoc
index 0f7bd5a2e..f79228b78 100644
--- a/src/site/asciidoc/best_practice.adoc
+++ b/src/site/asciidoc/best_practice.adoc
@@ -87,7 +87,11 @@ When not using WS-SecurityPolicy (see point above about
favouring the WS-Securit
approach), you should specify a signature algorithm to use on the receiving
side. This
can be done via WSHandlerConstants.SIG_ALGO ("signatureAlgorithm"). Setting
this property
to (e.g.) "http://www.w3.org/2000/09/xmldsig#rsa-sha1"; will ensure that the
signature
-algorithm allowed is RSA-SHA1 and not (e.g.) HMAC-SHA1. This latter point
requires the
-web services stack to set this property on the Request (it is known that
Apache CXF does
-this). See also the previous point about setting the key encryption transport
algorithm.
+algorithm allowed is RSA-SHA1 and not (e.g.) HMAC-SHA1. WSHandler itself never
calls
+`decodeAlgorithmSuite` internally, so this property only takes effect on the
receiving
+side if the web services stack explicitly invokes
`WSHandler.decodeAlgorithmSuite` (or
+otherwise sets an `AlgorithmSuite` on the `RequestData`) before processing the
security
+header -- Apache CXF's `WSS4JInInterceptor` does this. Stacks that call the
WSS4J engine
+directly without doing so get no enforcement from this property. See also the
previous
+point about setting the key encryption transport algorithm.
