Karthik Abram wrote:
>
> Also, the PasswordDigest handler mechanism in some ways seems useless. The
> handler expects one to retrieve a plain text password given a user
> identity.
> That assumes people have access to plain-text passwords in the first
> place!
> We store one-way hashed passwords and I suspect this is very common and
> also
> recommended. So the digest service would be rather useless in this
> scenario.
>
I think the error is with our example here[1], when we say
"setPassword("password")" (see the second shaded block). I think the
example should really say "setPassword("sdklfjhasdf");"--i.e., you want to
feed it the *encrypted* password, not the unencrypted one. (Dan, am I
correct here? I'll update the docs if that's the case.)
I book I had recently read, however, mentions other problems with this
mechanism--namely, that the client-side password encryption method used and
the server-side encryption method is rarely the same--stated another way, it
is strange for the client to need to know the encryption method of the
passwords on the server, so it can store the passwords in the same manner.
Glen
[1]
http://cwiki.apache.org/CXF20DOC/ws-security.html#WS-Security-UsernameTokenAuthentication
--
View this message in context:
http://www.nabble.com/CXF-security-without-throwing-exceptions-tp19227328p19229365.html
Sent from the cxf-user mailing list archive at Nabble.com.
