We're not using SAML so that's probably not coming into play. The
problem on the mailing list was not related to what we're seeing.

I am getting a wsse security header in the message coming from the
.NET client and there are nonce and created elements (I added logging
to WSSecurityEngine and UsernameToken to verify that the values
showing in SOAPMonitor are coming through to the WSS4J library).
However, the digested password does not match what
UsernameToken.doPasswordDigest generates.

I don't see any problems in the WSS4J code - it matches the spec just
fine. Is it possible there could be an issue with byte ordering?

Reply via email to