cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <>
Subject Re: Axis2 and CXF interop: Asymmetric binding and x509 endorsing token with signed parts assertion
Date Thu, 24 Jul 2014 20:35:39 GMT
I checked the behavior of Glassfish Metro web services runtime (v 2.3)
using the same security policy and it matches the one of Apache Rampart,
i.e. the response contains a single signature over the timestamp element.
I'm attaching the respective request and response messages for reference.


On Thu, Jul 24, 2014 at 1:30 AM, <> wrote:

> 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
> it.
> I will be glad if someone can help me to clarify this.
> Thanks,
>     Detelin

View raw message