Re: AW: AW: AW: STR-Transform question

[Pete Hendry]

Title: Nachricht

Dittmann, Werner wrote: Pete, about the ordering: this is how WSS4J implements it, but the WSS spec does not strictly mandates any order. What the WSS4J handler dois a step to enhance security processing by checking the order - this is by no means required by the spec and could be switched off. This is what I was trying to point out. The spec does not mandate order, but the interop scenarios do and WSS4J enforces an order. So, for a client sending a request with the Security children exactly as stated in the interop specification, the WSS4J server rejects scenarios 4, 5, 6 and 7 because the order in the config differs from that in the interop documents. The problem is simply that the configuration does not match the interop specification. As a concrete example consider the message extract: <wsse:Security xmlns:wsse="..." xmlns:wsu="..." env:mustUnderstand="1">   <wsse:BinarySecurityToken EncodingType="...#Base64Binary"       ValueType="...#X509v3"       wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken>   <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">     <ds:KeyInfo>       <wsse:SecurityTokenReference wsu:Id="id28008463">         <wsse:Reference URI="#id3125250" ValueType="...#X509v3"/>       </wsse:SecurityTokenReference>     </ds:KeyInfo>   </ds:Signature> </wsse:Security> In this case the BST does not define any namespaces. By your interpretation this BST should be used as-is with the prefix from the STR ("wsse"). Should it add a namespace prefix for this (WSS4J does)? But what about the wsu prefix used by wsu:Id?     Here the spec is clear: If Di is an XML security token (e.g., a SAML assertion or a <wsse:BinarySecurityToken> element), then let Ri' be Di.  That is if a BST is included thid is a copy of the original, with all attributes, etc. STRTransform does this using the  str = (Element) doc.importNode(str, true); method that copies the original node (deep clone) and imports it into the result document. Then this imported node becomes the new root node just below the document node. If the BST contains namespaces such as "SOAP" or "ds" then these are removed by the ouput c14n step if it is an exclusive c14n. Only if we need to construct a new BST and insert the token's raw bytes then we use the STR prefix. I am not arguing about the spec - we are in agreement there. What I am trying to explain is that WSS4J is not copying the BST it received but a modified version of it that was modified by the EnvelopeIdResolver calling XMLUtils.circumventBug2650(doc). In my original tests the BST I sent had no namespaces declared on it but because of the EnvelopeIdResolver all namespace declarations of the parents of the BST were copied to it before the STRTransform ran. This means that xmlns:wsse and xmlns:wsu were artificially added. If it were sticking to the spec as written above the STRTransform would simply copy the BST node to a new document as the root, but it would be the BST as it was in the original message not after the EnvelopeIdResolver messes around with it. If, as per the errata, C14N is only to be applied to the output of the STRTransform and not the input then I think WSS4J is adding namespace declarations that should not be there on the BST (it is not only copying it as above but instead it is modifying it then copying it). By chance the current behaviour of WSS4J is exactly as if the STR had been replaced by the BST in the original document and then C14N applied as this too pulls the namespace declarations onto the BST. Whether that is correct or not is the question. To go back to my example, if the BST arrives as   <wsse:BinarySecurityToken EncodingType="...#Base64Binary"       ValueType="...#X509v3"       wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken> the is that not what should be C14N'd on the output (assuming only output C14N)? This would result in   <wsse:BinarySecurityToken xmlns="" EncodingType="...#Base64Binary"       ValueType="...#X509v3"       wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken> Instead what WSS4J is C14Ning is   <wsse:BinarySecurityToken xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="..." xmlns:...       EncodingType="...#Base64Binary"       ValueType="...#X509v3"       wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken> with the result being   <wsse:BinarySecurityToken xmlns="" xmlns:wsse="..." xmlns:wsu="..."       EncodingType="...#Base64Binary"       ValueType="...#X509v3"       wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken> which is obviously different than if the original node had just been copied to the root of a document and C14N'd. Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]