WS Security UsernameToken– PasswordDigestExt and Base64

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

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

Terribly sorry about the multiple posts but when I went to Post it displayed no error and when I went to my email and found the link to verify it caused a number of posts to happen (probably because I refreshed the page that created the post). :(