ws-wss4j-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Coss (JIRA)" <>
Subject [jira] Commented: (WSS-54) UsernameTokenProcessor not processing unhashed UsernameToken
Date Sat, 14 Oct 2006 02:50:17 GMT
    [ ] 
Bob Coss commented on WSS-54:

   [[ Old comment, sent by email on Tue, 29 Aug 2006 10:28:05 -0500 ]]

That doesn't seem to make sense to me the way this is handled.
According to the way the callback is being processed, the only thing
that can be thrown is a UnsupportedCallbackException() or IOException.
In UsernameTokenProcessor, it will throw:

 throw new WSSecurityException(WSSecurityException.FAILURE,
                        "noPassword", new Object[]{user});

and not a

In the spirit of JAAS, shouldn't the handler be providing the value of
the password to the callback, and the UsernameTokoenProcessor evaluating
the password supplied in the token with the one from application?

> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>                 Key: WSS-54
>                 URL:
>             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, 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:
For more information on JIRA, see:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message