[jira] Updated: (WSS-54) UsernameTokenProcessor not processing unhashed UsernameToken

["Colm O hEigeartaigh (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/WSS-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Colm O hEigeartaigh updated WSS-54:
-----------------------------------

    Attachment: wss4j_wss54.patch


Please see the attached patch for a solution to this problem. The patch contains four things:

1) More extensive testing of processing Username Tokens.

2) Standard FAILED_AUTHENTICATION error codes are now returned, as suggested by Evan. In this way, no information is leaked to a potential attacker.

3) The UsernameTokenProcessor now does the authentication for both plaintext and password digest types. In both these cases, the sole function of the callback is to supply the password. This is more consistent than the existing solution.

4) By default custom password types are rejected. However, a configuration variable is added to WSSConfig and WSHandlerConstants, which enables the UsernameTokenProcessor to handle custom password types. In this case, all authentication is delegated to the callback handler. The reason they are rejected by default is to avoid a potential security hole when the implementing callback handler code leaves out a test for USERNAME_TOKEN_UNKNOWN.





> UsernameTokenProcessor not processing unhashed UsernameToken
> ------------------------------------------------------------
>
>                 Key: WSS-54
>                 URL: https://issues.apache.org/jira/browse/WSS-54
>             Project: WSS4J
>          Issue Type: Bug
>            Reporter: Bob Coss
>         Attachments: wss4j_wss54.patch
>
>
> 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.
-
You can reply to this email to add a comment to the issue online.


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