[
https://issues.apache.org/jira/browse/WSS-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Peter Palaga updated WSS-731:
-----------------------------
Description:
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.
It first complained I must not use // in my xPath expressions. That expected
with 4.0.2.
However I could not make it pass even when I removed // from the xPath in my
policy.
I tried
* An absolute path /soap:Envelope/soap:Header/wsse:Security/saml1:Assertion
* Single node name saml1:Assertion
* Trailing subpath soap:Header/wsse:Security/saml1:Assertion
and none of those worked.
The problem seems to be reproducible with 4.0.1 too. 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`.
h2. Reproducer
See SamlSTRTransformSignedElementsTest in
[https://github.com/apache/ws-wss4j/pull/738]
h2. 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.
h2. 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
```
h2. 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._
was:
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`.
h2. Reproducer
See SamlSTRTransformSignedElementsTest in
[https://github.com/apache/ws-wss4j/pull/738]
h2. 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.
h2. 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
```
h2. 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._
> 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
> Priority: Major
>
> 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.
> It first complained I must not use // in my xPath expressions. That expected
> with 4.0.2.
> However I could not make it pass even when I removed // from the xPath in my
> policy.
> I tried
> * An absolute path /soap:Envelope/soap:Header/wsse:Security/saml1:Assertion
> * Single node name saml1:Assertion
> * Trailing subpath soap:Header/wsse:Security/saml1:Assertion
> and none of those worked.
> The problem seems to be reproducible with 4.0.1 too. 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`.
> h2. Reproducer
> See SamlSTRTransformSignedElementsTest in
> [https://github.com/apache/ws-wss4j/pull/738]
> h2. 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.
> h2. 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
> ```
> h2. 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]
