There are two parts of the project at work here: wsdl2java and the request processing engine.
wsdl2java generates a lot of prefixes and uses them in code generation. Andrew could provide more insight into how the prefixes are generated and why. from the runtime perspective, the only time we generate a 'default' prefix (muse-op) is when we need to make the response element and we don't have a prefix to work with. other than that, what is sent from a client and what you return should go through without any change in prefix - of course, if wsdl2java generates a client that sends a generated prefix in the first place, then the runtime isn't going to 'fix' it to be some other prefix. we're careful to use the user's prefixes in the runtime, but those are based on the application's WSDL (final output of wsdl2java) and the client being used (often output of wsdl2java). > but it tends to truncate them > so that the prefix does not end in a vowel. ...where are you seeing this behavior? are you saying we're rabid anti-vowel-ites? ;) Dan "Vinh Nguyen \(vinguye2\)" <[EMAIL PROTECTED]> wrote on 04/09/2007 03:24:14 AM: > 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]
