ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colm O hEigeartaigh <>
Subject Re: WSS4J UsernameToken with Plain Text Password
Date Fri, 25 Jan 2013 09:46:02 GMT
Hi Ruchith,

In 1.5.x, for the digest case the WSPasswordCallback was not supplied the
password, but instead had to supply the password to the
UsernameTokenProcessor. For every other case, it was given the raw password
and expected to validate it itself. This was both inconsistent, and lead to
a security hole in leaving it up to the user CallbackHandler to make sure
that an exception was thrown for a non-matching plaintext case.

In 1.6.x, the WSPasswordCallback never gets the received password (by
default). The job is to supply the matching password to the
UsernameTokenValidator for comparison of either plaintext or digested
password. For the case that you don't have access to the plaintext
password, you have the option of overriding the relevant method in the
UsernameTokenValidator and performing some custom validation.


On Fri, Jan 25, 2013 at 3:36 AM, Ruchith Fernando <> wrote:

> Hi Devs,
> In the case where I store a salted+hashed password per each username,
> the WSPasswordCallback instance created by the
> UsernameTokenValidator[1] does not provide the password to carryout my
> own processing? In such a case, I will *not* have access to the
> original password of the user.  This was the behavior earlier when we
> used WSPasswordCallback.USERNAME_TOKEN_UNKNOWN [2].
> Have I overlooked something that is available to address this case?
> Thanks,
> Ruchith
> 1.
> 2.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Colm O hEigeartaigh

Talend Community Coder

View raw message