[
https://issues.apache.org/jira/browse/WSS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921715#action_12921715
]
Patrick Ryan edited comment on WSS-239 at 10/16/10 12:11 PM:
-------------------------------------------------------------
I attached wss4j-1.5.9-password-equivalence.patch which is a patch against
1.5.9 that adds support for password equivalence by indicating whether the
password should be Base64 decoded prior to calculating the UsernameToken
password digest or derived key. I added tests for the password digest
calculation as well as encryption and signature key deriviation.
The patch is agnostic to what the password equivalent is, only that it is
Base64 encoded. It could be the SHA-1 digest of the password or anything else.
So long as the producer and consumer agree on what the password equivalent is
and the password callbacks on both sides produce the Base64 encoded password
equivalent, this will work with any kind of password equivalent.
It is backwards compatible and not enabled by default. To enable it, just
invoke
WSSecurityEngine.getInstance().getWssConfig().setPasswordsAreEncoded(true);
After doing that, WSS4J will Base64 decode the password before doing the
password digest or key derivation calculation on password used with
UsernameToken. So in your WSPasswordCallback, you would return the Base64
encoded SHA-1 digest of the password instead of the password.
Alternately, you can control it at the time the UsernameToken header is
produced:
String username = "user";
String password = "password";
String encodedPasswordHash =
Base64.encode(MessageDigest.getInstance("SHA-1").digest(password.getBytes("UTF-8")));
// Create a username token that will take an encoded password.
WSSecUsernameToken builder = new WSSecUsernameToken(true);
builder.setUserInfo(username, encodedPasswordHash);
Document doc = unsignedEnvelope.getAsDocument();
WSSecHeader secHeader = new WSSecHeader();
secHeader.insertSecurityHeader(doc);
Document signedDoc = builder.build(doc, secHeader);
was (Author: pryan):
Attached is a patch against 1.5.9 that adds support for password
equivalence by indicating whether the password should be Base64 decoded prior
to calculating the UsernameToken password digest or derived key. I added tests
for the password digest calculation as well as encryption and signature key
deriviation.
The patch is agnostic to what the password equivalent is, only that it is
Base64 encoded. It could be the SHA-1 digest of the password or anything else.
So long as the producer and consumer agree on what the password equivalent is
and the password callbacks on both sides produce the Base64 encoded password
equivalent, this will work with any kind of password equivalent.
It is backwards compatible and not enabled by default. To enable it, just
invoke
WSSecurityEngine.getInstance().getWssConfig().setPasswordsAreEncoded(true);
After doing that, WSS4J will Base64 decode the password before doing the
password digest or key derivation calculation on password used with
UsernameToken. So in your WSPasswordCallback, you would return the Base64
encoded SHA-1 digest of the password instead of the password.
Alternately, you can control it at the time the UsernameToken header is
produced:
String username = "user";
String password = "password";
String encodedPasswordHash =
Base64.encode(MessageDigest.getInstance("SHA-1").digest(password.getBytes("UTF-8")));
// Create a username token that will take an encoded password.
WSSecUsernameToken builder = new WSSecUsernameToken(true);
builder.setUserInfo(username, encodedPasswordHash);
Document doc = unsignedEnvelope.getAsDocument();
WSSecHeader secHeader = new WSSecHeader();
secHeader.insertSecurityHeader(doc);
Document signedDoc = builder.build(doc, secHeader);
> Need ability to handle password "equivalent" between WSPasswordCallback and
> UsernameToken when it's binary data
> ---------------------------------------------------------------------------------------------------------------
>
> Key: WSS-239
> URL: https://issues.apache.org/jira/browse/WSS-239
> Project: WSS4J
> Issue Type: Improvement
> Components: WSS4J Core
> Affects Versions: 1.5.8
> Reporter: Jim Utter
> Assignee: Ruchith Udayanga Fernando
> Attachments: WSS-239-1_5_x-fixes.patch,
> wss4j-1.5.9-password-equivalence.patch
>
>
> 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/%3caanlktilndi8ijophc6lgv3mkp5_i_utrcfendkdk1...@mail.gmail.com%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscr...@ws.apache.org
For additional commands, e-mail: wss4j-dev-h...@ws.apache.org
