cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: Axis2 and CXF interop: Asymmetric binding and x509 endorsing token with signed parts assertion
Date Mon, 28 Jul 2014 14:48:51 GMT
Ok this is now working as expected on CXF trunk (3.1.x-fixes) +
3.0.x-fixes. I'm not merging the fix back to 2.7.x-fixes due to the size of
the change involved.


On Thu, Jul 24, 2014 at 9:35 PM, <> wrote:

> 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.
> Detelin
> 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

Colm O hEigeartaigh

Talend Community Coder

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