Emil, thanks for the info. Well, we did several interop tests with STRTransform some time ago with other implementations and tehy worked well. I also inspected the results several times, never saw this wrong behaviour.
After interop tests the implementation of c14n changed inside the xmlsec library. We didn't do any interop tests after these changes. Maybe here is a problem. It seems that the c14n instance does not clear its input or buffers the output from a previous usage. I'll ask in the xmlsec mailing list. Regards, Werner > -----Urspr�ngliche Nachricht----- > Von: Emil Marceta [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 15. M�rz 2005 02:58 > An: Dittmann Werner; [email protected] > Betreff: RE: STRTransfrom bug > > > > > May I ask you to give some more details about the misbehaviour > > of the c14n? > > Sure. In the [EMAIL PROTECTED], the canonicalization > results in the following: > > <wsse:SecurityTokenReference > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-20040 > 1-wss-wsse > curity-secext-1.0.xsd" > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401 > -wss-wssec > urity-utility-1.0.xsd" wsu:Id="STRSAMLId-4781685"><wsse:Reference > URI="#b383c5aab5db2078c485fba748fbc8f7" > ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX > -wss-saml- > token-profile-1.0#SAMLAssertion-1.1"></wsse:Reference></wsse:S > ecurityTok > enReference><temp xmlns="urn:X"><Assertion > xmlns="urn:oasis:names:tc:SAML:1.0:assertion" > AssertionID="b383c5aab5db2078c485fba748fbc8f7" > IssueInstant="2005-03-15T01:28:48.725Z" Issuer="www.example.com" > MajorVersion="1" MinorVersion="1"><AuthenticationStatement > AuthenticationInstant="2005-03-15T01:28:48.705Z" > AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" > ><Subject> > <NameIdentifier > NameQualifier="www.example.com">uid=joe,ou=people,ou=saml-demo > ,o=example > .com</NameIdentifier><SubjectConfirmation><ConfirmationMethod> > urn:oasis: > names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod></Subj > ectConfirm > ation></Subject></AuthenticationStatement></Assertion></temp> > > Contains the SecurityTokenReference and the Assertion for > some reason. > > The correct result there should be : > > <temp xmlns="urn:X"><Assertion > xmlns="urn:oasis:names:tc:SAML:1.0:assertion" > AssertionID="b383c5aab5db2078c485fba748fbc8f7" > IssueInstant="2005-03-15T01:28:48.725Z" Issuer="www.example.com" > MajorVersion="1" MinorVersion="1"><AuthenticationStatement > AuthenticationInstant="2005-03-15T01:28:48.705Z" > AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" > ><Subject> > <NameIdentifier > NameQualifier="www.example.com">uid=joe,ou=people,ou=saml-demo > ,o=example > .com</NameIdentifier><SubjectConfirmation><ConfirmationMethod> > urn:oasis: > names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod></Subj > ectConfirm > ation></Subject></AuthenticationStatement></Assertion></temp> > > The code that performs the substring operation after, and > removes the <temp> tag results in : > > erence > xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-20040 > 1-wss-wsse > curity-secext-1.0.xsd" > xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401 > -wss-wssec > urity-utility-1.0.xsd" wsu:Id="STRSAMLId-4781685"><wsse:Reference > URI="#b383c5aab5db2078c485fba748fbc8f7" > ValueType="http://docs.oasis-open.org/wss/2004/XX/oasis-2004XX > -wss-saml- > token-profile-1.0#SAMLAssertion-1.1"></wsse:Reference></wsse:S > ecurityTok > enReference><temp xmlns="urn:X"><Assertion > xmlns="urn:oasis:names:tc:SAML:1.0:assertion" > AssertionID="b383c5aab5db2078c485fba748fbc8f7" > IssueInstant="2005-03-15T01:28:48.725Z" Issuer="www.example.com" > MajorVersion="1" MinorVersion="1"><AuthenticationStatement > AuthenticationInstant="2005-03-15T01:28:48.705Z" > AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password" > ><Subject> > <NameIdentifier > NameQualifier="www.example.com">uid=joe,ou=people,ou=saml-demo > ,o=example > .com</NameIdentifier><SubjectConfirmation><ConfirmationMethod> > urn:oasis: > names:tc:SAML:1.0:cm:sender-vouches</ConfirmationMethod></Subj > ectConfirm > ation></Subject></AuthenticationStatement></Assertion> > > This is then submitted as the signature input. > > Since the same STRTransform was used on the sending and > receiving side this problem never surfaced. > > If the canonicalizer is instantiated again, for the second > operaiton: > canon = Canonicalizer.getInstance(canonAlgo); > buf = canon.canonicalizeSubtree(doc, "#default"); > that fixes the problem. > > It appears there is some side effect caused by the first > canocializer usage: > Canonicalizer canon = Canonicalizer.getInstance(canonAlgo); > byte buf[] = > canon.canonicalizeXPathNodeSet(input.getNodeSet()); > but I'm not familiar with that canonicalizer to comment on it. > > > > Maybe your fix helps to overcome the c14n problems > > with the default namespace ("xmlns=""). See the hacks > > to force the insertion of the empty namespace. > > I'm not sure about it, with the saml assertions the default > namespace is assigned to saml namespace. Maybe some other > test could confirm that? > > > > As an additional favour - can you provide some more info about > > your interop tests (deployment files?), the configuration you used, > > the use cases for this configuration etc .... it is always good to > > see things are working. > > I'm not allowed to provide much code, but here is a quick outline: > > - Sample SOAP messages get auto generated from from WSDL. > - Then the sample messages are decorated with various SAML statements. > This is where wss4j helped. We basically used existing wss4j unit > tests as the base. We got up and running very quickly. > - In the Layer7 firewall gateway the policy specifies the requirements > for the incoming message. > - Basically everything runs as a set of automated JUnit tests. > > Best regards, > > Emil Marceta >
