cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Axis2 and CXF interop: Asymmetric binding and x509 endorsing token with signed parts assertion
Date Wed, 23 Jul 2014 22:30:51 GMT
Hi CXF devs,
  I'm running into an interoperability issue between Apache Axis2 and CXF
and I need some help in identifying which framework is acting according to
the WS Security policy spec. The policy my customer is using is an
Asymmetric binding without integrity and confidentiality protection (no
signed/encrypted parts and elements) but using an additional x509 endorsing
supporting token that must sign certain parts (body & addressing To
header). The binding also requires that a timestamp is included.
The request message generated with both frameworks is similar
(Axis2/Rampart adds one additional BST but since the x509 token protection
token is same as the endorsing one, I assume this is not a problem).
However, I'm observing different behavior when generating the security
header of the response:
- Axis2/Rampart is signing just the timestamp element
- CXF is signing the same, plus the Body and the addressing To header

I'm attaching CXF request/response messages for reference.

I looked in the CXF code and find out that prior version 2.4.4, the
AsymmetricBindingHandler handled the supporting tokens on the requestor
side only. However, as part of CXF-3970
<>, it has been changed to
always handle them:

I believe this change results in the observed behavior and I'm wondering
whether this is according to the spec and Apache Rampart should follow the
same approach?

I'm attaching a patch for CXF's EndorsingSupportingTokenTest
that adds this scenario to the test case so whoever is interested can repro

I will be glad if someone can help me to clarify this.


View raw message