I posted a week ago when I noticed that the CallbackHandler is never invoked if a SOAP message is sent with <wsse:Password Type="PasswordText"> in the UsernameToken.
After digging around a bit more, I found this in the bug database - this behavior is by design from a patch to WSSecurityEngine and WSUsernameTokenPrincipal. See... http://issues.apache.org/jira/browse/WSFX-34 After reading the mailing list discussion I understand the reason behind the change. See... Subject = UsernameToken functionality in WSS4J http://ws.apache.org/mail/fx-dev/200408.gz (side note - is there a searchable archive of this list?) This places plaintext passwords outside of the WSS4J design. You implement a CallbackHandler to get the password that the WSSecurityEngine will validate against in the case of a digested password. In the case of a plaintext password you are on your own (and also must be aware that this special-case behavior requires custom handling - though it's not clear where this custom handling should go - an AxisHandler?). If I am using a library to manage my security and I am following its conventions, I want that library to behave consistently such that I shouldn't have to code special cases. I don't know a lot about the WSS4J architecture, but I'm going to throw out an idea to start a discussion on a more integrated solution. Is it possible for WSSecurityEngine to use a separate callback pathway in the plaintext case. The developer would implement their authentication logic here. This maintains consistency with existing behavior (using a callback configured in the server-config.wsdd) and ensures that the developer must address the plaintext case (preventing an unfortunate gap in security). Any ideas?
