[WSS-239] Need ability to handle password "equivalent" between WSPasswordCallback and UsernameToken when it's binary data

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.8
• Fix Version/s: 1.5.10, 1.6
• Component/s: WSS4J Core
• Assignee: Colm O hEigeartaigh
• Reporter: Jim Utter
• Created: 02/Aug/10 22:56
• Updated: 09/Nov/10 12:56
• Resolved: 09/Nov/10 12:55

Description

Per the oasis spec, the UsernamePassword is summarized by the algorithm:
base64(sha-1(nonce+created+password))

But, in some scenarios you don't store cleartext passwords - only the sha-1 hash
of them. The oasis spec allows this via what they claim as "..password
equivalent". The problem I'm running into is that the password equivalent
is sha-1(password) or ultimately this equivalent:
base64(sha-1(nonce+created+sha-1(password)))

When the applicability of this approach was questioned to the oasis list,
they confirmed it:
http://lists.oasis-open.org/archives/wss-dev/201006/msg00003.html

But, when using the wss4j WSPasswordCallback mechanism, the call expects the
password to be a string but the binary output of the digest if converted to
a string, then back to the bytes (by UsernameToken.doPasswordDigest()) does
not result in the original byte array - causing any digest calculations to
fail.

This was originally posted in the mailing list below where Colm suggested I provide a patch:
http://mail-archives.apache.org/mod_mbox/ws-wss4j-dev/201006.mbox/[e-mail]%3E