[
https://issues.apache.org/jira/browse/WSS-731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated WSS-731:
------------------------------------
Fix Version/s: 4.0.3
3.0.7
> 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
> Fix For: 4.0.3, 3.0.7
>
>
> 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]
