You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by andiklein <an...@goodkarmacompanies.com> on 2013/06/24 16:15:13 UTC
Re: WS-Security [UserNameToken] against encrypted database password
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.
Re: WS-Security [UserNameToken] against encrypted database password
Posted by andiklein <an...@goodkarmacompanies.com>.
Thanks Jason. I will definitely follow that UsernamePasswordPolicy approach
to further enforce that the correct UsernameToken and SSL encryption are
being used.
And thank you so much Ivan for that tip with the Validator. That is exactly
what I had hoped for.
--
View this message in context: http://cxf.547215.n5.nabble.com/WS-Security-UserNameToken-against-encrypted-database-password-tp561377p5729803.html
Sent from the cxf-user mailing list archive at Nabble.com.
Re: WS-Security [UserNameToken] against encrypted database password
Posted by Iván Brencsics <iv...@gmail.com>.
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 <ja...@pellcorp.com>
> 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" <an...@goodkarmacompanies.com>
> 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.
> >
>
Re: WS-Security [UserNameToken] against encrypted database password
Posted by Jason Pell <ja...@pellcorp.com>.
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" <an...@goodkarmacompanies.com>
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.
>