WSS4J UsernameToken with Plain Text Password

[Ruchith Fernando <ru...@gmail.com>]

Hi Devs,

In the case where I store a salted+hashed password per each username,
the WSPasswordCallback instance created by the
UsernameTokenValidator[1] does not provide the password to carryout my
own processing? In such a case, I will *not* have access to the
original password of the user.  This was the behavior earlier when we
used WSPasswordCallback.USERNAME_TOKEN_UNKNOWN [2].

Have I overlooked something that is available to address this case?

Thanks,
Ruchith

1. http://svn.apache.org/repos/asf/webservices/wss4j/tags/1_6_9/src/main/java/org/apache/ws/security/validate/UsernameTokenValidator.java
2. http://svn.apache.org/repos/asf/webservices/wss4j/tags/1_5_3/src/org/apache/ws/security/processor/UsernameTokenProcessor.java

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org

Re: WSS4J UsernameToken with Plain Text Password

[Ruchith Fernando <ru...@gmail.com>]

Hi Colm,

Thanks for the fast response.

On Fri, Jan 25, 2013 at 4:46 AM, Colm O hEigeartaigh
<co...@apache.org> wrote:
> Hi Ruchith,
>
> In 1.5.x, for the digest case the WSPasswordCallback was not supplied the
> password, but instead had to supply the password to the
> UsernameTokenProcessor. For every other case, it was given the raw password
> and expected to validate it itself. This was both inconsistent, and lead to
> a security hole in leaving it up to the user CallbackHandler to make sure
> that an exception was thrown for a non-matching plaintext case.

Regarding the security hole:
Do you mean the user may throw an exception with a message such as
"Invalid Password" leading to confirmation that a user exists?
But any exception can be wrapped/logged+ swallowed at the validator
and simply use that as a signal from the callback handler about
validation failure.
Also if we don't want to use exceptions we can have a flag in the
callback instance that the user can set when validation fails.

> In 1.6.x, the WSPasswordCallback never gets the received password (by
> default). The job is to supply the matching password to the
> UsernameTokenValidator for comparison of either plaintext or digested
> password. For the case that you don't have access to the plaintext password,
> you have the option of overriding the relevant method in the
> UsernameTokenValidator and performing some custom validation.

I was under the impression that plain text password case that I
explained was the scenario that one would use all the time. This is
because most of the time we won't store the plain text passwords to
validate against incoming plain text passwords and expected it to be a
part of the default behavior. Anyway I understand that this can be
overridden.

Thanks,
Ruchith

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
For additional commands, e-mail: dev-help@ws.apache.org

Re: WSS4J UsernameToken with Plain Text Password

[Colm O hEigeartaigh <co...@apache.org>]

Hi Ruchith,

In 1.5.x, for the digest case the WSPasswordCallback was not supplied the
password, but instead had to supply the password to the
UsernameTokenProcessor. For every other case, it was given the raw password
and expected to validate it itself. This was both inconsistent, and lead to
a security hole in leaving it up to the user CallbackHandler to make sure
that an exception was thrown for a non-matching plaintext case.

In 1.6.x, the WSPasswordCallback never gets the received password (by
default). The job is to supply the matching password to the
UsernameTokenValidator for comparison of either plaintext or digested
password. For the case that you don't have access to the plaintext
password, you have the option of overriding the relevant method in the
UsernameTokenValidator and performing some custom validation.

Colm.

On Fri, Jan 25, 2013 at 3:36 AM, Ruchith Fernando <
ruchith.fernando@gmail.com> wrote:

> Hi Devs,
>
> In the case where I store a salted+hashed password per each username,
> the WSPasswordCallback instance created by the
> UsernameTokenValidator[1] does not provide the password to carryout my
> own processing? In such a case, I will *not* have access to the
> original password of the user.  This was the behavior earlier when we
> used WSPasswordCallback.USERNAME_TOKEN_UNKNOWN [2].
>
> Have I overlooked something that is available to address this case?
>
> Thanks,
> Ruchith
>
> 1.
> http://svn.apache.org/repos/asf/webservices/wss4j/tags/1_6_9/src/main/java/org/apache/ws/security/validate/UsernameTokenValidator.java
> 2.
> http://svn.apache.org/repos/asf/webservices/wss4j/tags/1_5_3/src/org/apache/ws/security/processor/UsernameTokenProcessor.java
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: dev-help@ws.apache.org
>
>


-- 
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com