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-PasswordDigest-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.
