Don't do auth in wss4j interceptor just validate that the information has been provided. Then you can add interceptor in afterwards which has dependency on your db dao to get password from db has local password and compare.
Check out github.com/pellcorp The cxf JavaFirst project has a SecurityContextAuthenticationInterceptor that delegates to spring security but you can use your dao instead Set a ws-security validate.token false to your endpoint config so the username password are not checked On 25/06/2013 12:16 AM, "andiklein" <[email protected]> wrote: > I'm sorry, but I still do not understand HOW I am to intercept the > plaintext > password on the server side, so I can myself first hash it and compare the > result against a hashed value in the database. > > The only widely documented approach to using plaintext passwords I can find > is to use a CallbackHandler as WSS4JInInterceptor. But, as has been > mentioned here before, this is of course not an option, since we have no > way > of reconstructing the original password from the hash in our database in > order to feed that back into WSPasswordCallback.setPassword() > > It's a bit of a hen & egg conundrum ;) > > Could somebody please give me some pointers as to what alternative approach > I have to use to basically implement the same authentication and > authorization mechanism we can apply in a local GUI user login. > > That is I myself want to FIRST hash the plaintext password supplied along > with the user name in the request's security header / UsernameToken. And > only then do I wish to compare that hash against the hashed password in our > database to allow or deny the request. > > Any help would really be greatly appreciated. Many thanks in advance. > > > > -- > View this message in context: > http://cxf.547215.n5.nabble.com/WS-Security-UserNameToken-against-encrypted-database-password-tp561377p5729723.html > Sent from the cxf-user mailing list archive at Nabble.com. >
