Daniel,
I have found the piece of code in muse which breaks the namespace prefix.
The code snippet below is from
org.apache.muse.core.serializer.ElementSerializer, which is invoked by
the proxy to create the SOAP body from the Element parameter in the
proxy method:
public Element toXML(Object obj, QName qname)
{
if (obj == null)
return XmlUtils.createElement(qname);
// Erik's test
if((obj instanceof Element) &&
((Element) obj).getNodeName().equals("saml:Assertion")) {
Document doc = XmlUtils.EMPTY_DOC;
return (Element) doc.importNode((Element) obj, true);
}
// end test
return XmlUtils.createElement(XmlUtils.EMPTY_DOC, qname, obj);
}
The code between the comments is test code which I added. If I recognize
my message, I serialize it myself rather than sending it to
XmlUtils.createElement.
It used to be the case that my original document was transformed into
<pfx3:Assertion ...>
With this change I get
<saml:Assertion ...>
as it should be. The document is still re-indented though, so the
signature is still broken.
I had a look at the XmlUtils.createElement method, and what will happen
there is that it will work in embedChildren==true mode, in which case it
will throw away the saml:Assertion element which I supplied, and instead
create a new one. This new element will have a new namespace prefix. It
will then import the children of the supplied saml:Assertion element
into the new element, resulting in a new document with a changed prefix.
I am not familiar with the internals of muse, but it seems to me that
the correct behavior should be to use the invoker supplied element as it
is, and just check that it has the right QName. I suspect the
replacement code is there to make sure the element in the SOAP message
will have the right type.
I will also look into where the indentation happens. It seems to happen
after the proxy has created the SOAP message.
Best regards,
Erik
Daniel Jemiolo wrote:
> From a Muse perspective, the only time we add indentation is in
> XmlUtils.toString(), which is used if you turn on SOAP tracing (log-level
> = FINE in muse.xml). This just makes it easier to read the log file. You
> can stop the indentation all together by using this version of
> XmlUtils.toString():
>
> http://ws.apache.org/muse/docs/2.2.0/javadoc/org/apache/muse/util/xml/XmlUtils.html#toString(org.w3c.dom.Node,%20boolean,%20boolean)
>
> The point is that, from a Muse perspective, we don't add any additional
> whitespace nodes/indentation when processing the message - it just happens
> when we trace. If you look in the Axis2 service code, we just take the
> SOAP body as it comes from Axis2 (in Axiom form), convert it to DOM, and
> hand off the DOM tree to your method:
>
> http://svn.apache.org/viewvc/webservices/muse/trunk/modules/muse-platform-axis2/src/org/apache/muse/core/platform/axis2/AxisIsolationLayer.java?revision=522017&view=markup
>
> The Axiom -> DOM conversion is pretty straightforward - I could understand
> if we had *missed* something in the copying, but *adding* new things would
> be hard.
>
> Does this problem happen if you use the Mini SOAP engine (-j2ee mini)? If
> not, the problem may be with Axiom/Axis2. I've noticed that, like Axis
> 1.x, there are still cases where Axis2 adds in prefix/namespace
> declarations, and so the addition of blank/whitespace text nodes does not
> seem impossible.
>
>
>
> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/09/2007 02:51:06 AM:
>
>
>> Daniel Jemiolo wrote:
>>
>>> Can you give an example of the changing of XML prefixes? This was
>>>
> actually
>
>>> a major problem for us with the various SOAP engines we targeted
>>>
> (because
>
>>> WSRF is very dependent on prefixes staying the same), so we make sure
>>>
> not
>
>>> to modify prefixes in the request handling. Let me know what's
>>>
> happening.
>
>>> Also, are you signing things as part of the operation implementations?
>>>
>
>
>>> Normally this is done with something like WSS4J, which you can enable
>>>
> as
>
>>> an Axis2 handler (so the envelope will be completely finished when you
>>>
>
>
>>> sign or validate it).
>>>
>>> Dan
>>>
>>>
>>>
>>> Erik Rissanen <[EMAIL PROTECTED]> wrote on 04/08/2007 01:52:42 PM:
>>>
>>>
>>>
>>>> Hello,
>>>>
>>>> I am using Apache Muse 2.2.0 for implementing a web service. I need
>>>>
> to
>
>>>> pass digitally signed XML documents to the service. The problem I
>>>>
> have
>
>>>> is that Muse re-indents the XML and changes namespace prefixes. This
>>>> breaks the signatures.
>>>>
>>>> Is this a bug, feature or do I need to reconfigure muse somehow? I
>>>>
> tried
>
>>>> to search the web, this list and the bug tracking system, but I
>>>>
> couldn't
>
>>>> find anything.
>>>>
>>>> Regards,
>>>> Erik
>>>>
>>>>
>>>>
>> The signature is for an XML document which is signed standalone. I am
>> not signing the WS invocation itself, rather I am transmitting a
>> document which has been previously signed. So WSS4J is not what I am
>> looking for here.
>>
>> The schema for the messages looks like this:
>>
>> <xsd:schema elementFormDefault="qualified"
>> targetNamespace="http://sics.se/my-stuff">
>>
>> <xsd:element name="AddPolicy">
>> <xsd:complexType>
>> <xsd:sequence>
>> <xsd:element ref="saml:Assertion" />
>> </xsd:sequence>
>> </xsd:complexType>
>> </xsd:element>
>>
>> <xsd:element name="AddPolicyResponse" type="xsd:anyURI"/>
>> </xsd:schema>
>>
>> I use wsdl2java to generate a client proxy which has the following
>>
> method:
>
>> URI addPolicy(Element assertion) throws SoapFault;
>>
>> I read my signed document from disc and parse it into a DOM. I pass the
>> document element of this DOM to the above method. The document looks
>> like this (fragments only since it is quite long):
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>> <saml:Assertion xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
>> ID="ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c"
>> IssueInstant="2007-04-08T13:56:13Z" Version="2.0">
>> <saml:Issuer
>> Format="http://www.w3.org/2001/XMLSchema#string">...</saml:Issuer>
>> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
>> ...
>> <ds:Reference URI="#ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c">
>> ...
>> </ds:Signature>
>> <saml:Statement
>> xmlns:xacml-saml="urn:oasis:xacml:3.0:saml:assertion:schema:os"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> xsi:type="xacml-saml:XACMLPolicyStatementType">
>> <xacml:Policy xmlns="urn:oasis:names:tc:xacml:3.0:schema:os"
>> xmlns:xacml="urn:oasis:names:tc:xacml:3.0:schema:os" PolicyId="..."
>> RuleCombiningAlgId="..." Version="1.0">
>> <xacml:Target>
>> <xacml:DisjunctiveMatch>
>> ...
>>
>>
>> On the server side wsdl2java generates the following:
>>
>> public URI addPolicy(Element Assertion) throws Exception {
>> ....
>> }
>>
>> When I receive the document here it doesn't look right. notice the
>> prefix "pfx3" and the excessive amount of indentation:
>>
>> <pfx3:Assertion ID="ID_191adef5-f5a9-40b6-a0c1-c23ca7de3c6c"
>> IssueInstant="2007-04-08T13:56:13Z" Version="2.0">
>>
>>
>>
>> <saml:Issuer
>>
>>
> Format="http://www.w3.org/2001/XMLSchema#string">...</saml:Issuer><ds:Signature>
>
>> ....
>>
>> <ds:SignedInfo>
>> </ds:KeyInfo></ds:Signature><saml:Statement
>> xmlns:xacml-saml="urn:oasis:xacml:3.0:saml:assertion:schema:os"
>> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>> type="xacml-saml:XACMLPolicyStatementType">
>>
>> <xacml:Policy PolicyId="..." RuleCombiningAlgId="..."
>> Version="1.0">
>>
>>
>> <xacml:Target>
>>
>>
>>
>> <xacml:DisjunctiveMatch>
>>
>>
>> xsi:type has also been changed to just type in the saml:Statement
>>
> element.
>
>> I got the above document by encoding the received Assertion element to a
>> file in the capability implementation. I used the apache xml-security
>> canonicalizer for the encoding:
>>
>> Canonicalizer canon = Canonicalizer.getInstance
>> (Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
>> FileOutputStream fouts = new
>>
> FileOutputStream("/tmp/tete2.xml");
>
>> fouts.write(canon.canonicalizeSubtree(Assertion));
>> fouts.close();
>>
>> I don't think it is the canonicalizer which messes up the file. I also
>> tried to use the Muse XmlUtils class for this encoding, in which case
>> the document looks different from above. (The indentation is prettier.)
>>
>> I am using the axis2 engine and I deploy the war in tomcat 5 on Fedora
>> Core 6 Linux.
>>
>> Thanks for your assistance,
>> Erik
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]