Hello Glen,
thanx for the comprehensive explaination. We are using SSL and without nonce I
see the point, that we do not get any further security from PasswordDigest over
PasswordText.
Independent of this fact, Colm gave the hint, how to implement the handler in
order to accept PasswordDigest but reject PasswordPlain. Sticking with the
common example, the handler then could look this way:
public void handle(Callback[] callbacks) throws IOException,
UnsupportedCallbackException {
logger.debug("ServerPasswordCallback.handle called.");
WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
if (pc.getUsage() != WSPasswordCallback.USERNAME_TOKEN) {
throw new IOException("Wrong password type. The only allowed type
is '" + WSConstants.PW_DIGEST + "'");
}
if (pc.getIdentifier().equals("joe")) {
// set the password on the callback. This will be compared to the
// password which was sent from the client.
pc.setPassword("password");
}
}
Thanx again for your support.
Regards,
Rick
-----Original Message-----
From: Glen Mazza [mailto:[email protected]]
Sent: Monday, July 13, 2009 4:54 PM
To: [email protected]
Subject: RE: Configured WS-Security UsernameToken PasswordDigest accepts
PasswordText
Ah yes. I thought I saw that problem before:
http://issues.apache.org/jira/browse/CXF-2150
But besides this issue, because CXF has not yet implemented the server-side
nonce storage (a largely necessary component for UsernameToken usage) you may
wish to use Glassfish Metro for UT profile security[1]. CXF is much better
with the normal X.509 profile instead of username token.
Be careful not to view password digest as necessarily more helpful than plain
text because it is encrypted back and forth -- you should still be requiring
SSL as a minimum (as Metro does here), which makes plain text password usage
OK. Another issue, user passwords on the server-side are usually stored in
encrypted format (in LDAP or a database). Normally, you take the incoming
*plain text* password, apply the same encryption method as that used by your
local LDAP or database, and if they're the same, let the user in. If you take
an incoming password digest, it can be much less helpful because, by definition
of digests, you will not be able to unencrypt it so you can subsequently
re-encrypt it to compare it to the stored LDAP/DB value. Using password
digests pretty much requires the encryption mechanism used to create the digest
be the *same* as the encryption method used by the LDAP/DB, so you can do a
direct comparison between the two--a regulation that may be difficult for your
team to enforce.
HTH,
Glen
[1]
http://www.jroller.com/gmazza/entry/implementing_ws_security_using_usernametokens
Rick.Janda wrote:
>
> Hello Glen,
>
> thank you for your response.
>
> I read [1] before and now once again but I can not find any
> explaination, how to make my service accept only PasswordDigest and reject
> PasswordText.
>
> <entry key="passwordType" value="PasswordDigest"/>
>
> as contructor argument for WSS4JInInterceptor seems to be ignored
> completely. With this configuration, the interceptor hands over all
> PasswordText authentication requests to my handler that was designed
> to autheticate PasswordDigest requests. So I'm not sure, what the
> passwordType parameter is good for at the server side, if the it does
> not declare the authentication type that my service accepts.
>
> And within the callback handler I can not check for PasswordDigest as
> of
> pc.getPasswordType()
> will return 'null', if a security header with PasswordDigest was
> submitted, thus
>
> WSPasswordCallback pc = (WSPasswordCallback) callbacks[0];
>
> if (!WSConstants.PW_DIGEST.equals(pc.getPasswordType())) {
> throw new IOException("Wrong password type. The only
> allowed type is '" + WSConstants.PW_DIGEST + "'");
> }
>
> in the callback handler does also not work, too.
>
> I'm sorry, that I have to bother you again with my issue, but I would
> be really grateful, if you could have a look at it again.
>
> Thank you in advance,
> Rick
>
> -----Original Message-----
> From: Glen Mazza [mailto:[email protected]]
> Sent: Friday, July 10, 2009 9:41 PM
> To: [email protected]
> Subject: Re: Configured WS-Security UsernameToken PasswordDigest
> accepts PasswordText
>
>
> Yes, check[1], search on the text "Note that for the special case of a
> plain-text password". Hopefully this will get changed relatively soon[2].
>
> [1] http://cwiki.apache.org/CXF20DOC/ws-security.html
> [2] https://issues.apache.org/jira/browse/WSS-183
>
> Glen
>
>
> Rick.Janda wrote:
>>
>> Do you have idea, how to make CXF rejecting anything else than
>> PasswordDigest?
>> Or have I missed something in the documentation?
>>
>
>
> --
> View this message in context:
> http://www.nabble.com/Configured-WS-Security-UsernameToken-PasswordDig
> est-accepts-PasswordText-tp24432779p24433414.html
> Sent from the cxf-user mailing list archive at Nabble.com.
>
>
>
--
View this message in context:
http://www.nabble.com/Configured-WS-Security-UsernameToken-PasswordDigest-accepts-PasswordText-tp24432779p24463286.html
Sent from the cxf-user mailing list archive at Nabble.com.
