AW: AW: AW: STR-Transform question

[Dittmann, Werner]

Title: Nachricht

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. Another topic about ordering is mentioned in the spec, chapter 5.2: As elements are added to a <wsse:Security> header block, they SHOULD be prepended to the existing elements. As such, the <wsse:Security> header block represents the signing and encryption steps the message producer took to create the message. This prepending rule ensures that the receiving application can process sub-elements in the order they appear in the <wsse:Security> header block, because there will be no forward dependency among the subelements. Note that this specification does not impose any specific order of processing the subelements. The receiving application can use whatever order is required. WSS4J mandates such a processing because it stepwise builds the request and each step is completed before the next step is performed. Other comment see inline. Regards, Werner -----Ursprüngliche Nachricht----- Von: Pete Hendry [mailto:[EMAIL PROTECTED] Gesendet: Donnerstag, 22. September 2005 12:24 An: Dittmann, Werner Cc: [EMAIL PROTECTED]; wss4j-dev@ws.apache.org Betreff: Re: AW: AW: STR-Transform question Dittmann, Werner wrote: I now have all 7 scenarios working between our client and Axis 1.2.1 and WSS4J. Some comments and problems: 1) The WSS4J server configuration (deploy.wsdd) has the order of steps wrong for scenarios 4, 5, 6 and 7. The Timestamp should be the first step (in the interop docuemnt it appears last in the security header which means it happens first). In the configuration the Timestamp is last and so the tests fail if the Timestamp is added first as per the interop documents. Werner: True, the interop defines a specific order. However, the order of actions was not relevant during the interop tests. Also the WSS spec does not mandate any order, the only thing that should be (and WSS4J mandates this) that elements that shall be signed or encrypted must be available before you sign/encrypt them. In other words if you like to sign (and/or encrypt) a Timestamp then you must add the Timestamp (using the Timestamp action) before the Signature/Encrypt actions. This is not quite right. When WSS4J tests the actions it received it checks the results are in exactly the order they are defined in the list of actions. What I said in my last email is what you say here - it shouldn't matter the order as long as things are present at the right time, and that is the way our code works - but this is not how WSS4J checks the actions - it is strict and so a Security header formed to follow the interop spec fails against WSS4J acting as the server. The relevant code in WSDoAllReceiver is for (int i = 0; i < size; i++) {     if (((Integer) actions.get(i)).intValue() !=             ((WSSecurityEngineResult) wsResult.get(i)).getAction()) {         throw new AxisFault(             "WSDoAllReceiver: security processing failed (actions mismatch)");     } } which enforces the order precisely. Werner: AFAI understand the WSS spec: - if it is a direct BST - just copy it, but as a "node set of its own", that is without the sorrunding original document - if it is a indirect reference to a token - get the token's raw bytes, create a new BST, using the "same namespace prefix" as the original STR (I interpret this as using the original STR's element prefix to identify the WSS namespace.) Nothing is said about to use additional or other namespaces for this new BST. The only namespace relevant topic I see here is the requirement to have the empty namespace defined if it was not defined in the element. At the last step c14n the resulting BST, then transform into a byte stream. This byte stream is then signed. Werner: In any case the result of the STR is a new (small) document in itself that was created by parsing the input nodes. 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.   Should a namespace prefix also be added for that? And if there were any other attributes in other namespaces? The way WSS4J works (as you know of course ;) ) is that the call to XMLUtils.circumventBug5650() in the resolver pulls all the namespace definitions in scope onto the BST. This BST with all the namespace prefixes is then used and passed to the C14er with the result being that the C14N'd BST has all the used namespaces defined on it. From this example, the result of the STRTransform in WSS4J is   <wsse:BinarySecurityToken xmlns="" xmlns:wsse="..." xmlns:wsu="..."       EncodingType="...#Base64Binary"       ValueType="...#X509v3"       wsu:Id="id3125250">MIIDDD...</wsse:BinarySecurityToken> My question is, is this the correct behaviour? The spec says nothing about adding namespace definitions to the BST to ensure all namespaces are defined. If the BST were just to be taken from the document and considered in isolation these prefixes would not resolve unless the namespace declarations are inserted. I'm not sure if the WS-I InclusiveNamespace stuff also is required for this Transform algorithm. We did some WS-I InclusiveNamespace stuff for other elements (Signature and Encryption) but we hit sever interop problem. Thus we made this configurable but it is switched off by default. If there were interop problems with this then I will do the same. Thanks for the tip. Pete --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]