Forum Discussion
I ran across your post as I was in need of an older password digest algorithm when communicating with Amadeus Web Services (WBS). After diving through some articles on WSE and SoapUI I think this may just be a simple bug based on how I believe this was intended to be used.
A SoapUI article describes PasswordDigestExt - "The PasswordDigestExt option is non-standard and should only be used for interop issues where the message receiver desires an extra SHA-1 Hash of the password."
https://www.soapui.org/soapui-projects/ws-security.html
The implementation under the covers does a Sha-1 encryption of the clear text password then does a base64 encoding to turn it into a string.
UsernameEntry.java:
if (PASSWORD_DIGEST_EXT.equals(passwordType)) { try { MessageDigest sha = MessageDigest.getInstance("SHA-1"); sha.reset(); sha.update(password.getBytes("UTF-8")); password = Base64.encode(sha.digest()); } catch (Exception e) { SoapUI.logError(e); } }
Looking further into how the WSSecUsernameToken consumes that information to build xml I found this check for if the password is encoded then call a different overload that will decode the string back into the raw bytes that is the sha-1 of the clear text password:
UsernameToken.java
public void setPassword(String pwd) {
if (pwd == null) {
if (passwordType != null) {
throw new IllegalArgumentException("pwd == null but a password is needed");
} else {
// Ignore setting the password.
return;
}
}
rawPassword = pwd; // enhancement by Alberto coletti
Text node = getFirstNode(elementPassword);
try {
if (hashed) {
if (passwordsAreEncoded) {
node.setData(doPasswordDigest(getNonce(), getCreated(), Base64.decode(pwd)));
} else {
node.setData(doPasswordDigest(getNonce(), getCreated(), pwd));
}
} else {
node.setData(pwd);
}
if (passwordType != null) {
elementPassword.setAttributeNS(null, "Type", passwordType);
}
} catch (Exception e) {
if (DO_DEBUG) {
LOG.debug(e.getMessage(), e);
}
}
}
Since the WSSecUsernameToken extends WSSecBase, the setUserInfo method will only take a string typed password. That known, the authors did intend for the string password to possibly be encoded but their abstraction (instead of having an overload that accepts a byte[]), was to set a boolean of passwordsAreEncoded.
I am going to create a pull request suggesting that this was a bug in the UsernameEntry.java code (but I am making a big assumption here on the intention) and that this would resolve the issue for those interoperating with an older password digest need.
If I am correct the fix would be setting telling the UsernameToken that the password is encoded:
if (PASSWORD_DIGEST_EXT.equals(passwordType)) {
try {
MessageDigest sha = MessageDigest.getInstance("SHA-1");
sha.reset();
sha.update(password.getBytes("UTF-8"));
password = Base64.encode(sha.digest());
token.setPasswordsAreEncoded(true);
} catch (Exception e) {
SoapUI.logError(e);
}
}
I havfe al
Related Content
- 3 years ago
- 5 years ago
- 3 years ago
Recent Discussions
- 10 days ago