Thanks very much for the help. I did not read the PasswordText part carefully and thought the validation for plain password text is also delegated to CXF. It works after making the change.
Mark Glen Mazza wrote: > > Again, I would send a plaintext password over HTTPS (my tutorial is using > DIGEST for passwords, but it is an easy switch to plaintext)--it will be > encrypted along with everything else in the soap:envelope that way, but > with plaintext your web service provider will get the actual password and > can use it to validate against the database, using whatever mechanism you > database provides to authenticate (or you can use the same hash with the > plaintext pwd that you already use to stored the hashed version in the > database table.) > > As shown in the WS-Security guide in the CXF documentation[1], you'll > notice the password verification function is designed differently if you > use a plaintext password instead of a password digest--as for how you can > validate, take a look at the password verification function for plaintext > passwords and I think that will answer your question. > > HTH, > Glen > > [1] > http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-UsernameTokenAuthentication > > > > Mark2008 wrote: >> >> Hi Glen, >> >> Thanks for your reply. >> >> Here is our situation: >> >> 1. We use HTTPS for encryption >> 2. The password value in our database is hashed, NOT encrypted. So I can >> not decrypt it back its original value and uses >> WSPasswordCallback.setPassword. >> >> I guess the typicaly way will NOT work unless the client know what >> hashing function we are using and then send the generated hashed value >> through the web service. >> >> Is there anyway I can bypass the WSPasswordCallback.handleUserNameToken >> (or other methods) that validate the INPUT-password against the supplied >> hashed value from database? >> >> For example, If I can get the INPUT-password, I can hash it with the >> algorithm at server side and then compare with the database value. This >> should be very simple. >> >> Or is it possible I can modify/update the INPUT-password with its hashed >> value at server side? >> >> Thanks for your help, >> >> Mark >> >> Mark2008 wrote: >>> >>> I am integrating the WS-Security UserNameToken approach to our existing >>> application. The existing application stores the password in one-way >>> hashing format with the following code snippet (plaintext is the plain >>> password text and we use https) >>> >>> ------------------------------------------------------ >>> MessageDigest md = MessageDigest.getInstance("SHA"); >>> md.update(plaintext.getBytes("UTF-8")); >>> byte raw[] = md.digest(); >>> String hash = (new BASE64Encoder()).encode(raw); >>> String newPassword = hash.substring(0,19); >>> ------------------------------------------------------ >>> >>> I tried both PasswordDigest and PasswordText, but the security token can >>> not be authenticated. >>> WSSecurityException: The security token could not be authenticated or >>> authorized at >>> org.apache.ws.security.processor.UsernameTokenProcessor.handleUsernameToken(UsernameTokenProcessor.java:129) >>> >>> How do I specify the encrypt/hash algorithm? or should I hash the >>> INPUT-password using the above code first and then set the database >>> hashed password WSPasswordCallback.setPassword or just bypass the >>> WSPasswordCallback.handleUserNameToken by comparing those two >>> programmatically? >>> >>> Any idea? What's the best practice? >>> >>> Thanks, >>> >>> Mark >>> >>> >> >> > > -- View this message in context: http://www.nabble.com/WS-Security--UserNameToken--against-encrypted-database-password-tp20737774p20758246.html Sent from the cxf-user mailing list archive at Nabble.com.
