If you would want them to validate even more, it would appear WSS4J should be using another class for these callbacks besides javax.security.auth.callback.CallbackHandler, which again does not appear designed for validation because of the deeply constrained types of exceptions it can throw.
I also noticed that, because we require a different type of service-side callback handler (http://tinyurl.com/cw7tas) depending on whether cleartext or digest passwords are being used (because of the way WSS4J presently operates), if I switch from password digest to cleartext on the client side, the service starts to accept everything if its callback handler has not been correspondingly updated to now start validating instead of providing passwords--which is a rather large security hole. It would be good if WSS4J were designed in such a way that the CXF service-side callback hander would *not* need to be changed depending on whether cleartext or digest passwords are being sent from the client. Glen dkulp wrote: > > > CC the wss4j list as that's probably more appropriate. > > Actually, with 1.5.6, the callbacks are also used to verify trust for any > RSAKeyValue tokens found in the message. Thus, they are used for various > validation things. > > In the future, I'd like to see the callbacks actually do more validation > prior > to things being used. For example, we could validate the trusts of the > x509 > certs that are found PRIOR to using the cert for decryption. If the cert > isn't trusted, why spend the processor time doing the decryption and such. > Right now, we do all the processing, then after the fact, we check to make > sure the certs that were used are OK. Timestamps could be checked > immediately, etc... > > Dan > > > On Tue March 24 2009 8:32:25 am Glen Mazza wrote: >> BTW, I will update our online example to use a IOException for a bad >> cleartext password, as that appears to be the less incorrect of our two >> exception choices. It seems strange, though, that WSS4J treats digest >> and >> cleartext passwords differently, relying on the CallbackHandler to do the >> validation for the latter: http://tinyurl.com/cuqblz. CallbackHandlers >> do >> not appear meant to do validation, or else they would have a >> BadPasswordSuppliedException or similar exception-throwing capability. >> >> Glen >> >> Glen Mazza wrote: >> > Technically, I guess you're limited to not just any exception but >> > specifically a IOException or a UnsupportedCallbackException subclass, >> as >> > those are the only two types of exceptions declared throwable by the >> > handle() method: >> >> http://java.sun.com/javase/6/docs/api/javax/security/auth/callback/Callback >>Handler.html > > -- > Daniel Kulp > [email protected] > http://www.dankulp.com/blog > > -- View this message in context: http://www.nabble.com/Package-for-SecurityException--tp22669188p22683472.html Sent from the cxf-user mailing list archive at Nabble.com.
