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? >
