Thank you for your response. How about this: * rename the property "passwordCallbackClass" to "digestCallbackClass" * add support for a property "plaintextCallbackClass" * this new class would also implement CallbackHandler * in WSSecurityEngine.handleUsernameToken, an else block to the if(ut.isHashed) could handoff password processing to the plaintextCallbackClass (throwing an exception if it wasn't defined) and if handle threw an Exception, WSSecurityEngine would exit with a FAILED_AUTHENTICATION (that leaves all plaintext processing under the full control of the user)
However, because I'm not thoroughly versed in the source code, I don't know how that affects the creation/usage of WSUsernameTokenPrinicpal from there. It's not ideal because the user is required to throw an exception from handle in order to trigger failure (as opposed to returning a value that can be checked), but it is consistent with existing functionality, doesn't require major changes (afaik), and doesn't let plaintext passwords escape authentication. -a On Thu, 17 Mar 2005 10:41:58 +0100, Dittmann Werner <[EMAIL PROTECTED]> wrote: > Andy, > > sorry for not answering your first e-mail. > > It would be a good idea to have a consitent behaviour > of the security engine. I'll really appreciate any > ideas. > > Regards, > Werner > > > -----Urspr�ngliche Nachricht----- > > Von: Andy Kriger [mailto:[EMAIL PROTECTED] > > Gesendet: Mittwoch, 16. M�rz 2005 20:31 > > An: [email protected] > > Betreff: Plaintext UsernameToken passwords? > > > > > > 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? > > >
