[ http://issues.apache.org/jira/browse/WSS-54?page=comments#action_12459509
]
Ever A. Olano commented on WSS-54:
----------------------------------
I think I can live with the callback handler determining from the usage
(USERNAME_TOKEN or USERNAME_TOKEN_UNKNOWN) whether or not to do the validation
itself. However, In UsernameTokenProcessor.java:
} else if (cb != null) {
WSPasswordCallback pwCb = new WSPasswordCallback(user, password,
pwType, WSPasswordCallback.USERNAME_TOKEN_UNKNOWN);
callbacks[0] = pwCb;
try {
cb.handle(callbacks);
} catch (IOException e) {
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
} catch (UnsupportedCallbackException e) {
throw new WSSecurityException(WSSecurityException.FAILURE,
"noPassword", new Object[]{user});
}
}
It should throw FAILED_AUTHENTICATION instead of FAILURE. Either that or have
another exception, say, FailedAuthenticationException that cb.handle() may
throw so that this code can differentiate between a real "noPassword" scenario
or a failed authentication.
By the way, this is probably being nitpicky, but we should probably get rid of
the "noPassword" resource and return the same error message for failed
authentication instead. That way, a hacker would not be able to tell whether
or not the username they tried to authenticate with exists.
Thanks,
Ever
> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
> Key: WSS-54
> URL: http://issues.apache.org/jira/browse/WSS-54
> Project: WSS4J
> Issue Type: Bug
> Reporter: Bob Coss
> Assigned To: Davanum Srinivas
>
> The UsernameTokenProcessor will not authenticate anything but a UsernameToken
> that was hashed with a nonce and timestamp. Anything else that is passed to
> it will create a valid principal regardless of what the implementations
> password callback handler does. This is creating confusion and preventing
> WSS4J from being used for anything where the the UsernameToken is passed
> plainly. It is understood that doing this in a production environment is
> discouraged, but it is usefull to have this implementation work as expected
> so that the framework can be experimented with and evaluated.
> Specifically, in UsernameTokenProcessor.java, for a UsernameToken that is not
> of hashed, nothing is done with the WSPasswordCallback object after the call
> to the password handler handle method is invoked. Since nothing is done with
> it, the code drops through and sets up a valid principal with the userid and
> returns. There is no way to signal a
> WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
