[
https://issues.apache.org/jira/browse/CXF-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alessio Soldano updated CXF-5248:
---------------------------------
Description:
I have an endpoint whose WSDL has the following policy:
{noformat}
<wsp:Policy wsu:Id="MyPolicy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
{noformat}
I've configured the client so that the provided SAML2 assertion is self signed.
The SamlTokenInterceptor deals with the request on server side; a RequestData
instance is built up in 'processToken(Element tokenElement, final SoapMessage
message)', but no signature crypto is configured in it. As a consequence the
validation later fails in SignatureTrustValidator#validate(..) because no
crypto can be retrieved.
I assume the security configuration from the incoming message should be
propagated to the RequestData instance constructed in the interceptor.
I'm attaching a patch (against 2.7 branch) that solves my specific failure, but
I'm not sure if other props should be propagated too.
was:
I have an endpoint whose WSDL has the following policy:
{noformat}
<wsp:Policy wsu:Id="MyPolicy">
<wsp:ExactlyOne>
<wsp:All>
<sp:SupportingTokens>
<wsp:Policy>
<sp:SamlToken
sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
<wsp:Policy>
<sp:WssSamlV20Token11/>
</wsp:Policy>
</sp:SamlToken>
</wsp:Policy>
</sp:SupportingTokens>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
{noformat}
I've configured the client so that the provided SAML2 assertion is self signed.
The SamlTokenInterceptor deals with the request on server side; a RequestData
instance is built up in 'processToken(Element tokenElement, final SoapMessage
message)', but no signature crypto is configured in it. As a consequence the
validation later fails in SignatureTrustValidator#validate(..) because no
crypto can be retrieved.
I assume the security configuration from the incoming message should be
propagate to the RequestData instance constructed in the interceptor.
I'm attaching a patch (against 2.7 branch) that solves my specific failure, but
I'm not if other props should be propagated.
> Signed SAML assertion validation error w/ SupportingTokens only policy
> ----------------------------------------------------------------------
>
> Key: CXF-5248
> URL: https://issues.apache.org/jira/browse/CXF-5248
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Alessio Soldano
> Assignee: Colm O hEigeartaigh
> Fix For: 3.0.0, 2.6.10, 2.7.7
>
> Attachments: CXF-5248.txt
>
>
> I have an endpoint whose WSDL has the following policy:
> {noformat}
> <wsp:Policy wsu:Id="MyPolicy">
> <wsp:ExactlyOne>
> <wsp:All>
> <sp:SupportingTokens>
> <wsp:Policy>
> <sp:SamlToken
> sp:IncludeToken="http://docs.oasis-open.org/ws-sx/ws-securitypolicy/200702/IncludeToken/AlwaysToRecipient";>
> <wsp:Policy>
> <sp:WssSamlV20Token11/>
> </wsp:Policy>
> </sp:SamlToken>
> </wsp:Policy>
> </sp:SupportingTokens>
> </wsp:All>
> </wsp:ExactlyOne>
> </wsp:Policy>
> {noformat}
> I've configured the client so that the provided SAML2 assertion is self
> signed.
> The SamlTokenInterceptor deals with the request on server side; a RequestData
> instance is built up in 'processToken(Element tokenElement, final SoapMessage
> message)', but no signature crypto is configured in it. As a consequence the
> validation later fails in SignatureTrustValidator#validate(..) because no
> crypto can be retrieved.
> I assume the security configuration from the incoming message should be
> propagated to the RequestData instance constructed in the interceptor.
> I'm attaching a patch (against 2.7 branch) that solves my specific failure,
> but I'm not sure if other props should be propagated too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
