[
https://issues.apache.org/jira/browse/CXF-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17324850#comment-17324850
]
Colm O hEigeartaigh commented on CXF-8438:
------------------------------------------
Hi,
This asymmetry between the sending and receiving actions is well known. For
example see this test configuration:
[https://github.com/apache/cxf/blob/19b6ed46b2d1b25547166174f1714daeace1c333/systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action/client.xml#L384]
[https://github.com/apache/cxf/blob/19b6ed46b2d1b25547166174f1714daeace1c333/systests/ws-security/src/test/resources/org/apache/cxf/systest/ws/action/server.xml#L308]
It's been like this a long time, and so I don't want to make any changes in
case of breaking anyone's existing configuration.
> Out/In Interceptor requires additional IN action when using SAMLTokenSigned
> ---------------------------------------------------------------------------
>
> Key: CXF-8438
> URL: https://issues.apache.org/jira/browse/CXF-8438
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Jan Monterrubio
> Priority: Major
> Attachments: image-2021-03-18-13-52-27-215.png,
> image-2021-03-18-13-56-06-919.png, image-2021-03-18-13-58-10-702.png,
> image-2021-03-18-13-58-44-532.png, image-2021-03-18-14-02-05-830.png,
> image-2021-03-18-14-03-06-005.png
>
>
> h2. Issue
> I am using the "SAMLTokenSigned" action in my client and server setup.
> h3. Out Transport
> Using the action in the WSS4JOutInterceptor works correctly and ends up
> setting a single HandlerAction when sending data down to doSenderAction:
> !image-2021-03-18-13-52-27-215.png!
> The action constant is ST_SIGNED:
> !image-2021-03-18-13-56-06-919.png!
> h3. Inbound Data
> When processing the header, there seems to be an additional action
> discovered.
> The first WSSecurityEngineResult is a SAMLToken:
> !image-2021-03-18-13-58-10-702.png!
> A second WSSecurityEngine result is added based on the SignatureProcessor:
> !image-2021-03-18-13-58-44-532.png!
> The failure then happens when checkReceiverResultsInAnyOrder is invoked.
> We have 1 recorded action and 2 found actions in the wsResult value:
> !image-2021-03-18-14-02-05-830.png!
> When checking if that additional action, which is a signature is part of the
> recorded action, the check will fail and our interceptor will produce a fault:
> !image-2021-03-18-14-03-06-005.png!
> h3. Work Around
> On the server side, we can set the actions to both a "SAMLTokenSigned" and
> "Signature":
> {code}
> // TODO work around here is to add Signature to the actions
> inProps.put("action", "SAMLTokenSigned Signature");
> {code}
> h2. Questions
> 1. Should the SAMLSignedToken handling also add a receiver action of SIGN
> (WSConstant.SC)?
> h3. Sample that reproduces the issue
> https://github.com/AnEmortalKid/cxf/tree/sign_saml_test/distribution/src/main/release/samples/ws_security/signed_saml_token
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
