Title: Nachricht
Emil,
 
thanks very much for this report. The STRTransform is a real
difficult part and it took some time to get ist up and running
during our interop tests.
 
May I ask you to give some more details about the misbehaviour
of the c14n? Maybe your fix helps to overcome the c14n problems
with the default namespace ("xmlns=""). See the hacks
to force the insertion of the empty namespace.
 
As an additional favour - can you provide some more info about
your interop tests (deployment files?), the configuration you used,
the use cases for this configuration etc .... it is always good to
see things are working.
 
Best regards,
Werner
-----Urspr�ngliche Nachricht-----
Von: Emil Marceta [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 14. M�rz 2005 07:23
An: [email protected]
Cc: Emil Marceta
Betreff: STRTransfrom bug

Hi,

I'm new with the wss4j project, slightly less new with
the Web Services Security, and first my greetings to
the team.

I was playing with wss4j trying to run the interop test
scearios against the Layer7 product - WS-Security firewall.

The goal was to use the SAML SOAP token profile interop
scenarios as client against the engine.

And at the end everything worked fine - Layer7 uses a
different xml security library, and have a homegrown saml
api.

I did find what I think is a small bug in the STRTransfrom
class.

It appears that the Canonicalizer instance need to be recreated
for the next operation. It appears it keeps some state from
the previous call in the same method, resulting in wrong
output after the second call.

After I applied the patch in the attachment, I had a wss4j
interop tests producing signed SAML tokens and Layer7 engine
consuming them without problem.

Best Regards,
Emil Marceta   

Reply via email to