[
https://issues.apache.org/jira/browse/WSS-239?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12927430#action_12927430
]
Jim Utter commented on WSS-239:
-------------------------------
I believe this is acceptable as it solves the problem via convention (of
assuming all passwords are base64 encoded) rather than changing a ton of code.
Basically, representing the binary password in a base64 form until it's
consumed in the digest calculation is a portable method of overloading the
String password signatures to accept such an argument. The patch I had
originally submitted was very complicated compared to this solution. With
Patrick's patch, I would simply need to ensure I base64 encode my external
password equivalent prior to passing it into the wss4j signatures and configure
wss4j to decode it prior to using it in any digest calculations.
Unfortunately, wss4j is not the only library that handles passwords as strings
so base64 provides a consistent mechanism to move binary passwords around as
long as they can be decoded prior to being used.
Prior to seeing Patrick's post I had started to pursue another route which
allowed the developer to subclass UsernameToken and eliminated it's static
methods. This allowed me to specify my own implementation of UsernameToken via
the existing action/processor config methods and simply overload the
doPasswordDigest() signature to do basically the same thing that Patrick is
doing above as custom code (decode a base64 encoded string prior to digesting).
Thus, the outcome would be the same - but Patrick's solution has much less
code movement/refactoring. It would be nice to be able to overload
UsernameToken methods but Patrick's solution is much more surgical to our
immediate problem and I believe would provide no risk to any backwards
compatiblity.
> 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/%[email protected]%3e
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
