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.
2) The WSS4J STRTransform ignores InclusiveNamespaces (it doesn't check
for them).
This was where my problem lay - I was including them - as they affect
what is produced
by canonicalization. I removed them from my request and it worked Ok.
The fact
that WSS4J C14Ns both the input and output has no effect on the
output (the input
C14N can be removed I believe without affecting the outcome).
3) I suspect (but have not tested) that inclusive C14N will not work
with the WSS4J
STRTransform except for a reference to a BinarySecurityToken and the
same for
InclusiveNamespaces.
I will try to explain... The WSS4J STRTransform class relies on the
XMLUtils.circumventBug2650() method having been called before the
transform is called. This is necessary so that all the namespace
declarations
in the context of the STR are copied to it and also to the BST (if
there is one).
When STR has a refernece to a BST all is well because the BST has all the
namespace definitions on it (curtesy of the circumventBug2650 method).
This is an important point because when the STRTransform class does
C14N of the output it does not do it for the whole document but instead
creates a new Element to parent the BST which was copied or created.
This new Element is not in the context of the original STR (i.e. it
does not
share the same ancestor hierarchy) but is instead the root node. This
means
all the namespace context from the STR would be lost if it had not
luckily
been copied by circumventBug2650.
For the case of the STR being a reference to a BST all is well, even if
InclusiveNamespaces were defined I believe this would work. However,
if the STR is a KeyIdentifier or IssuerSerial then the BST is
created. In
this case it does not have all the namespace definitions of the parents
of the STR in its context so when inclusive C14N is performed (or
exclusive C14N with InclusiveNamespaces defined) the context
namespaces are not available to include on the BST node.
I hope that all makes sense to someone! Inclusive C14N may not be so
important (especially since WS-I mandates exclusive only) but
InclusiveNamespaces may be more so (since WS-I also mandates them).
The problem can only really be reliably fixed by inserting the BST into
the copy of the document (which has already been made) in place of the
STR and then C14Ning the BST in this context.
The algorithm I have written does not C14N the input (as per the errata)
and it still works against WSS4J so that could probably be removed from
the WSS4J transform code.
I hope this is useful (and understandable).
Pete
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
