[
https://issues.apache.org/jira/browse/CXF-8438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17304945#comment-17304945
]
Jan Monterrubio commented on CXF-8438:
--------------------------------------
The Saml Subject confirmation plays part into whether the Signature action is
required or not. From the profile for sender vouches:
{quote}
The attesting entity, (presumed to be) different
from the subject, vouches for the verification of
the subject. The receiver MUST have an existing
trust relationship with the attesting entity. The
attesting entity MUST protect the assertion in
combination with the message content against
modification by another party.
{quote}
So, by using sender-vouches, we have to sign some elements which ends up
resulting in a "ds:Signature" element being caught by the processor, and
finding a "Signature" action.
> 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)
