[
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_revised.patch
Here is a revised patch for this issue. This patch preserves the original
functionality whereby the authentication of plaintext password or unknown
password types is delegated to the callback handler. We really need to revisit
this architecture for 2.0, as the callback handler architecture is not being
used correctly.
This patch contains three 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) 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.
> 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_revised.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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
