cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunil Bapat <suba...@gmail.com>
Subject TransportBinding and SignatureConfirmation
Date Thu, 04 Oct 2012 17:30:33 GMT
I am working on writing a client to a web service using CXF 2.6.2. The
service has a security policy which uses TransportBinding with SAML
EndorsingSupportingTokens. The policy also requires Signature Confirmation
(<sp:RequireSignatureConfirmation/>).

What is happening is that the client calls the service correctly with the
required security elements. The response from the server contains a
Signature Confirmation element, and the response fails with the error:
Received a SignatureConfirmation element, but there are no stored signature
values

Debugging through the CXF code, here's what is happening:

- After configuring the client, the WSS11Builder calls
setRequireSignatureConfirmation(true) based on the policy.

- In the constructor of AbstractBindingBuilder, it initializes the
signatures array property with an empty array, and puts it in the message
as follows:
message.getExchange().put(WSHandlerConstants.SEND_SIGV, signatures)

- In the TransportBindingHandler.handleEndorsingToken (line 300), it calls
addSig, which eventually calls the doSignature. However, the signature is
never added to the signatures array. (SymmetricBindingHandler and
AsymmetricBindingHandler do a signatures.add)

- As a result when the service response comes to the WSS4JInInterceptor, it
calls checkSignatureConfirmation in WSHandler, which retrieves the
savedSignatures using
List<byte[]> savedSignatures =
            (List<byte[]>) getProperty(reqData.getMsgContext(),
WSHandlerConstants.SEND_SIGV);

- This array is empty, since the signature was never added by
TransportBindingHandler. Therefore it throws the above exception.

The question is - is this a bug, or is it by design that the
SignatureConfirmation does not work with TransportBinding, and that they
are not allowed together?

Thanks
Sunil.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message