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 <[email protected]> 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, <[email protected]> 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, <[email protected]> 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 >
