cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <detelinyorda...@gmail.com>
Subject Re: Axis2 and CXF interop: Asymmetric binding and x509 endorsing token with signed parts assertion
Date Wed, 30 Jul 2014 15:49:31 GMT
Thanks a lot Colm, I checked the newly added test case and now the behavior
seems fine.

Detelin


On Mon, Jul 28, 2014 at 5:48 PM, Colm O hEigeartaigh <coheigea@apache.org>
wrote:

> 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