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. Colm. On Fri, Jan 25, 2013 at 3:36 AM, Ruchith Fernando < [email protected]> 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. > http://svn.apache.org/repos/asf/webservices/wss4j/tags/1_6_9/src/main/java/org/apache/ws/security/validate/UsernameTokenValidator.java > 2. > http://svn.apache.org/repos/asf/webservices/wss4j/tags/1_5_3/src/org/apache/ws/security/processor/UsernameTokenProcessor.java > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Colm O hEigeartaigh Talend Community Coder http://coders.talend.com
