Hi,
If I understand correctly your question, your problem is that you dont
access the password in the CallbackHandler, so you cannot hash it and
compare it with the database.
I ran into the same problem recently, and I solved it by registering an
org.apache.ws.security.validate.Validator instead of a CallbackHandler. So
for instance:
jaxws:endpoint:
<jaxws:properties>
<entry key="ws-security.ut.validator"
value-ref="sqlTokenValidator"/>
</jaxws:properties>
where:
<bean id="sqlTokenValidator" class="org.my.SqlTokenValidator">
<property name="jdbcTemplate" ref="jdbcTemplate"/>
</bean>
and finally SqlTokenValidator:
public class SqlTokenValidator implements Validator {
...
@Override
public Credential validate(Credential credential, RequestData data)
throws WSSecurityException {
...
UsernameToken usernameToken = credential.getUsernametoken();
String username = usernameToken.getName();
String password = usernameToken.getPassword();
... hash the password
... sql_auth(username, hash password)
... if failed throw new
WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
return credential;
}
Ivan
2013/6/25 Jason Pell <[email protected]>
> 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.
> >
>
