Hi, >From what I remember this differs based on which parser is used to read in the data. We kept having issues with "smart" parsers that decided to strip out prefixes that we're "used." The problem was that the prefixes were used, but they were used at text nodes. So if some element looked like:
<foobar>prefix:someName</foobar> We ended up losing the prefix prefix because no element had a reference to it. This would also break your signatures. >From my understanding, there is some laxness when comparing two XML fragments for equality and prefixes and whitespace are considered fuzzy according to the specs. Is there no way for the signatures you are generating to consider these isomorphisms? Thanks, Andrew Andrew Eberbach Autonomic Computing (919) 254-2645 T/L: 444-2645 [EMAIL PROTECTED] Erik Rissanen <[EMAIL PROTECTED]> 04/09/2007 03:53 AM Please respond to [email protected] To [email protected] cc Subject Re: Muse breaks digital signatures Yes, this probably explains the pfx3 prefix. However, the solution is not to use the prefix defined in the wsdl. Rather, the proxy should let the prefix which is supplied by the caller be and just check that the element is in the right namespace. In fact, a prefix should not be required at all. Back when I was using axis1, I had a similar issue. Axis1 didn't like that there was no prefix. I used to just write <AnElement xmlns="..."> but Axis1 changed this to <ns5:AnElement xmlns:ns5="..."> This also breaks signatures. I worked around this by setting explicit prefixes myself. I have not tried this with axis2/muse, but I wouldn't be surprised if this is still around. Axis2/muse seems to have some bugs: 1. It replaces the prefix of the "root" element of the parameter passed to the proxy. 2. It re-indents the XML. This also breaks XML signatures. 3. It changes prefixes of xml attributes. Note the "xsi:type" vs "type" in my document. In this case it isn't just the prefix, since this changes the actual namespace of the type attribute. (And possibly it would generate prefixes like Axis1 if I would use default namespaces instead of prefixes.) Regareds, Erik Vinh Nguyen (vinguye2) wrote: > I've seen this behavior, too, where Muse doesn't quite preserve the > prefixes. > > For example, in the generated client proxy classes, the various QName[] > properties seem to have prefix values that are generated by default > (i.e. pfx0, pfx1, pfx2) instead of what is defined in the wsdl. > > Also, when the server sends the xml response to the client, it does seem > to use the prefixes defined in the wsdl, but it tends to truncate them > so that the prefix does not end in a vowel. > > For us, it doesn't cause errors, but it sometimes make it difficult to > read the xml trace and determine if certain elements have correct data, > or are formatted correctly. > > I suspect this behavior is because namespace prefixes are not always > used in wsdls (as prefixes are not required), so maybe Muse has its own > "smart logic" for handling prefixes but isn't always consistent with it? > > > -----Original Message----- > From: Erik Rissanen [mailto:[EMAIL PROTECTED] > Sent: Sunday, April 08, 2007 11:51 PM > To: [email protected] > Subject: Re: Muse breaks digital signatures > > > 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:Si > gnature> > > > .... > > <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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
