Hi Colm,
We tried to extend this
org.apache.cxf.sts.token.validator.UsernameTokenValidator defined in the
cxf-transport.xml of Fediz IDP-STS with our custom one and replaced the bean
definition ("transportUsernameTokenValidator"). Unfortunately this bean is
never instantiated. Instead, the validation is always done by
"org.apache.ws.security.validate.UsernameTokenValidator" which is registered by
default in the WSSConfig.
What is the correct way to register our own UsernameTokenValidator?
Thanks in advance,
Regards,
Fran.
El 02/02/2012, a las 15:38, Colm O hEigeartaigh escribió:
> Hi,
>
> The CallbackHandler is only responsible for retrieving the (plaintext)
> password corresponding to the username that was received. It doesn't
> do any validation, that's done in the UsernameTokenValidator.
>
> So for the use-case where you don't have access to the plaintext
> password, but instead know the hashed password to compare directly
> against the received hashed password, you could implement your own
> UsernameTokenValidator, and configure the CXF security runtime to use
> this validator for UsernameTokens. In this case, the CallbackHandler
> wouldn't retrieve any password, as it doesn't know how to access the
> plaintext password.
>
> Colm.
>
> On Thu, Feb 2, 2012 at 10:03 AM, Francisco Serrano
> <francisco.serr...@mimacom.com> wrote:
>> Hi list,
>>
>> We are trying to integrate the STS into our solution for SSO but we
>> encountered an issue that is hard to solve.
>>
>> For the moment, the token validator uses a callback to be able to
>> verify the correct username and password to deliver the token.
>>
>> The problem appears when you need to store hashed passwords and
>> check. There would be needed some mechanism no to set the current password
>> to the WSPasswordCallback to be verified directly against the string value
>> of the password but to check it agains a hashed value.
>>
>> The following code is coming from the PasswordCallbackHandler:
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> public void handle(Callback[] callbacks) throws IOException,
>> UnsupportedCallbackException {
>>
>> if (getPasswords() == null || getPasswords().size() == 0)
>> return;
>>
>> for (int i = 0; i < callbacks.length; i++) {
>> if (callbacks[i] instanceof WSPasswordCallback) { // CXF
>> WSPasswordCallback pc = (WSPasswordCallback) callbacks[i];
>>
>> String pw = getPasswords().get(pc.getIdentifier());
>> pc.setPassword(pw);
>> }
>> }
>> }
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> The correct/original password and the one provided is evaluated at
>> the UsernameTokenValidator
>> (org.apache.ws.security.validate.UsernameTokenValidator). Method:
>> verifyDigestPassword (called from the "verifyPlaintextPassword" method).
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>> if (!origPassword.equals(password)) {
>> throw new
>> WSSecurityException(WSSecurityException.FAILED_AUTHENTICATION);
>> }
>>
>> -----------------------------------------------------------------------------------------------------------------------------
>>
>>
>> I could imagine that it could be set a flag to indicate that the
>> password should be checked instead of compared and also the algorithm to be
>> used for the digest check.
>>
>> Any suggestion about how this could/should be done? Any other idea?
>>
>> Thanks in advance.
>>
>> Fran.
>>
>
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com
>
