[jira] [Commented] (WSS-281) Password set to null in UsernameTokenValidator

["Simeon Kirov (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/WSS-281?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13939124#comment-13939124 ] 

Simeon Kirov commented on WSS-281:
----------------------------------

This is completely wrong design decision, which above everything, breaks the compatibility with previous versions. Further down in your code you have the follwoing:

        String origPassword = pwCb.getPassword();
        if (origPassword == null) {
            if (log.isDebugEnabled()) {
                log.debug("Callback supplied no password for: " + user);
            }
            throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
        }

So, if the developer who uses this framework doesn't provide the real password of the user to the callback handler, the method will fail with WSSecurityException.

It is not WSS4J framework's job to validate the password. It should only provide it as is.

The developer who uses this framework may need the password in order to do authentication, using APIs provided by the container of the application or by some other means. Probably the developer will not have access at all to the real password or it might be hashed.

The behaviour you are describing is still guaranteed by the your final lines of code:

            if (!origPassword.equals(password)) {
                throw new WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
            }

So, if the developer wants to use WSS4J for password validation, he/she still can make it without breaking compatibility with previous versions.

Simeon

> Password set to null in UsernameTokenValidator
> ----------------------------------------------
>
>                 Key: WSS-281
>                 URL: https://issues.apache.org/jira/browse/WSS-281
>             Project: WSS4J
>          Issue Type: Bug
>          Components: WSS4J Core
>    Affects Versions: 1.6
>         Environment: linux, cxf, jetty 6.10
>            Reporter: Nicolas Poirot
>            Assignee: Colm O hEigeartaigh
>              Labels: UsernameTokenValidator
>
> When trying to do basic authentication in Soap header with UserNameToken, token is well read from XML, but badly passed to password callback.
> Line 165 of org.apache.ws.security.validate.UsernameTokenValidator :
> WSPasswordCallback pwCb = 
>             new WSPasswordCallback(user, null, pwType, WSPasswordCallback.USERNAME_TOKEN, data);
> The password is set to null, while it has been correcty read just before.
> Proposed patch :
> Index: src/main/java/org/apache/ws/security/validate/UsernameTokenValidator.java
> ===================================================================
> --- src/main/java/org/apache/ws/security/validate/UsernameTokenValidator.java	(révision 1098991)
> +++ src/main/java/org/apache/ws/security/validate/UsernameTokenValidator.java	(copie de travail)
> @@ -163,7 +163,7 @@
>          boolean passwordsAreEncoded = usernameToken.getPasswordsAreEncoded();
>          
>          WSPasswordCallback pwCb = 
> -            new WSPasswordCallback(user, null, pwType, WSPasswordCallback.USERNAME_TOKEN, data);
> +            new WSPasswordCallback(user, password, pwType, WSPasswordCallback.USERNAME_TOKEN, data);
>          try {
>              data.getCallbackHandler().handle(new Callback[]{pwCb});
>          } catch (IOException e) {



--
This message was sent by Atlassian JIRA
(v6.2#6252)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org