So I tested an existing client written using Axis2 1.4.1 and Rampart 1.4 
against the Web service today written using Axis2 1.5.1 and Rampart 1.5.  With 
encryption and signature turned off things went fine, but when encryption and 
signature were turned on, the client sent a proper request that was understood 
by the server, but the response sent by the server caused the client to error 
out with "Expecting one of {classList}".

This is almost certainly due to the fact that "classList" is supposed to have 
the empty default Namespace, but Axis2 1.5.1 and Rampart 1.5 are changing that 
namespace to the parent namespace of 
"http://atrium.bmc.com/2009/01/classes/types"; on encrypting and signing the 
body.

I am relatively sure this isn't correct behavior, but I am unable to get the 
Axis2 1.5.1/Rampart 1.5 combo to work differently.  Is this a known issue with 
Rampart?  Has anyone run into this before?  Is there any way to work around the 
issue and make the responses preserve the proper default namespaces?

From: Doughty, Michael [mailto:michael_doug...@bmc.com]
Sent: Sunday, February 14, 2010 12:57 AM
To: axis-user@ws.apache.org
Subject: Strange issue with Axis2 setting improper default namespaces in 
responses

We've been porting our Web services from another provider to Axis2.  Both 
support XML bean bindings, and we used them in our original implementation, so 
that has made the porting easier than it would have been otherwise.

However, I've run into an odd issue that I haven't caught up to now using the 
testing tool we use during dev.  The old tool is properly setting the default 
namespace to child elements to empty, which allows the responses to be properly 
handled by the clients.  However, the Axis2 services seem to be setting the 
default namespace in each case to the parent namespace.  This causes validation 
of the responses against the WSDL and the schemas to be incorrect.

So then I decided to see what happens in the Axis2-based responses when I turn 
security off and just accept a UsernameToken without encryption or signature.  
Turns out the response is just fine when I do that, as this snippet shows:

  <ListClassesOutput
    xmlns="http://atrium.bmc.com/2009/01/classes/types";>
   <classList
    xmlns="">
    <list>
     <namespaceName>BMC.CORE</namespaceName>
     <className>BMC_Mainframe</className>
    </list>
    <list>
     <namespaceName>BMC.CORE</namespaceName>
     <className>BMC_Printer</className>
    </list>
   </classList>
   <status
    xmlns=""/>
   <extensions xmlns=""
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
  </ListClassesOutput>

However, the minute I turn the Signature and Encryption components on in the 
Rampart configuration, I get the bad behavior again, as shown here:

<ListClassesOutput xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
  <classList xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
    <list xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
     <namespaceName xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC.CORE</namespaceName>'
     <className xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC_Mainframe</className>
   </list>
   <list xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>
     <namespaceName xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC.CORE</namespaceName>
     <className xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#";>BMC_Printer</className>
    </list>
  </classList>
  <status xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"/>
  <extensions xmlns="http://atrium.bmc.com/2009/01/classes/types"; 
xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"; 
xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd";
 xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; xsi:nil="true"/>
</ListClassesOutput>

So it seems to be not so much a problem with Axis2 as it is with Rampart.  In 
every case, the xmlns default namespace of child elements are listed as the 
full namespace of the parent when Rampart Signature/Encryption are turned on, 
but are set properly when it is not.  As a result, our stricter clients are 
failing right away because they see the message as incomplete.

Am I missing something here?  Is there an option in Rampart to rectify this?  I 
am using Axis2 1.5.1 with Rampart 1.5.

Reply via email to