cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <cohei...@apache.org>
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.

Colm.


On Thu, Jul 24, 2014 at 9:35 PM, <detelinyordanov@gmail.com> 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, <detelinyordanov@gmail.com> 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
>> <https://issues.apache.org/jira/browse/CXF-3970>, it has been changed to
>> always handle them:
>>
>>
>> https://fisheye6.atlassian.com/viewrep/cxf/rt/ws/security/src/main/java/org/apache/cxf/ws/security/wss4j/policyhandlers/AsymmetricBindingHandler.java?r1&r2=ec64c5d373f28de7d346c976b6834bb7e3c11fde
>>
>> 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
>> <https://svn.apache.org/repos/asf/cxf/trunk/systests/ws-security/src/test/java/org/apache/cxf/systest/ws/tokens/EndorsingSupportingTokenTest.java>
>> 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
http://coders.talend.com

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