Hi Sanjay, When using Username Tokens, there are two scenarios.
1.) Using the plain text password 2.) Using the hashed password In both scenarios, in client side, when Username Builder is building the Username Token it calls the callback with the WSPasswordCallback.USERNAME_TOKEN usage and the callback fills the password according to the user id. In the sever side , in plain text password scenario , Usename Token Processor calls the password callback with the passedword and the usage set to WSPasswordCallback.USERNAME_TOKEN_UNKNOWN and the callback validates and throws and exception if the authentication fails. However in the hashed password scenario, Usename Token Processor calls the callback with the usage set to WSPasswordCallback.USERNAME_TOKEN and the callback simply fills the password and return it. Then the Usename Token Processor does the check to see the hashes match. So when implementing the service's password callback you need to handle both scanarios. assuming that the samples given in the Rampart bistro only implements > the client side of things and doesn't do any password validation on the > service side. Yes, got your point. If the password is plain text then there will be no validation in the current implementation of password callback in the samples. Anyway we can do it in the same class by changing the behavior according to the usage value. But I also think in practical scenarios most of the time we need to have two password callback classes one for client and one for service. Regards, Nandana
