Peter Palaga created WSS-731:
--------------------------------
Summary: StAX SignedElements policy rejects a SAML assertion
signed through STR-Transform
Key: WSS-731
URL: https://issues.apache.org/jira/browse/WSS-731
Project: WSS4J
Issue Type: Bug
Reporter: Peter Palaga
Assignee: Colm O hEigeartaigh
I have hit this when upgrading to WSS4J 4.0.2 in Quarkus CXF my SignedElements
test happened to require signature for an assertion node signed through an
STR-Transform.
The problem seems to be reproducible before 4.0.2. This is how my Agent is
describing it. I hope it makes sense.
-----
The streaming WS-SecurityPolicy implementation rejects a SAML 1.1
sender-vouches
assertion covered by the SOAP message signature through an STR-Transform. The
same
message passes WSS4J StAX signature and subject-confirmation validation when
the
policy processor is absent. Adding a `SignedElements` policy targeting the
assertion causes `Assertion must be signed`.
## Reproducer
See SamlSTRTransformSignedElementsTest in
https://github.com/apache/ws-wss4j/pull/738
## Expected behavior
Both inbound passes succeed. The STR-Transform includes the referenced
assertion
in the signature digest, so the assertion satisfies `SignedElements` even
though
it has no embedded signature. This use of STR-Transform is described in the
[OASIS SAML Token Profile, section
3.5.2.3](https://docs.oasis-open.org/wss-m/wss/v1.1.1/os/wss-SAMLTokenProfile-v1.1.1-os.html).
The reproducer asserts successful processing; it deliberately does not treat
the
current exception as the expected result.
## Actual behavior
The inbound pass with policy enforcement throws `XMLStreamException`, wrapping
`WSSecurityException` and `PolicyViolationException`:
```text
Element
/\{http://schemas.xmlsoap.org/soap/envelope/}Envelope/\{http://schemas.xmlsoap.org/soap/envelope/}Header/{http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity
-secext-1.0.xsd}Security/\{urn:oasis:names:tc:SAML:1.0:assertion}Assertion must
be signed
```
## Analysis
`PolicyInputProcessor` uses `DocumentContext.isInSignedContent()` when
processing
the assertion's start element. Because STR signature coverage is resolved
separately, it emits a negative `SignedElementSecurityEvent` directly to
`PolicyEnforcer`.
`WSSSignatureReferenceVerifyInputProcessor.buildTransformerChain()`
subsequently
verifies the assertion from the STR's buffered XML events, and
`processElementPath()` emits positive signature coverage for the assertion.
Those positive events pass through `InboundWSSecurityContextImpl`, which
buffers
them until the operation is known. The policy enforcer encounters the earlier
negative event first, and `SignedElementsAssertionState` rejects the only
policy
alternative before the positive coverage can satisfy it.
The policy processing needs to account for deferred STR coverage of the actual
assertion. Leaving the global "in signed content" flag set would incorrectly
cover unrelated elements and is not a suitable fix.
_AI-generated by Codex on behalf of Peter Palaga._
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
