Re: AW: AW: STR-Transform question

[Pete Hendry]

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. 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? 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]