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.

  

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