This has been mentioned up by several people now. I have pointed out previously that ignoring PasswordText creates a situation where developers are using the WSS4J library for security but the security can be bypassed if the client uses PasswordText. The developer is expected to roll their own solution for an aspect of the security that is in the specification but is not covererd by WSS4J (and it's not obvious that one needs to do this since the behavior is undocumented).
I proposed a solution a while back that would maintain consistency within WSS4J but never heard a response. From my previous email... 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. On 5/3/05, Dittmann Werner <[EMAIL PROTECTED]> wrote: > Ruchith, > > WSS4J does not authticate if PasswordText is specified, it > just returns the data to the application (Axis service). > Also, in case of username token the password is optional. > > Indeed you are right about the specification of the password > callback: we shall make it optional in case of PasswordText. > > Regards, > Werner > > > -----Urspr�ngliche Nachricht----- > > Von: Ruchith Fernando [mailto:[EMAIL PROTECTED] > > Gesendet: Dienstag, 3. Mai 2005 11:26 > > An: WS-FX > > Betreff: UsernameToken authentication when a plain text > > password is used > > > > > > Hi, > > > > I noticed that WSSecurityEngine doesn't authenticate the UsernameToken > > when passwordType="PasswordText". > > > > -------------------------------------------------------------- > > ------------------------------------------------------------- > > public WSUsernameTokenPrincipal handleUsernameToken(Element token, > > CallbackHandler cb) throws WSSecurityException { > > ..... > > ..... > > if (ut.isHashed()) { > > //Authenticates the UT > > } > > > > WSUsernameTokenPrincipal principal = new > > WSUsernameTokenPrincipal(user, ut.isHashed()); > > principal.setNonce(nonce); > > principal.setPassword(password); > > principal.setCreatedTime(createdTime); > > > > return principal; > > } > > > > -------------------------------------------------------------- > > ------------------------------------------------------------- > > > > Is the above behaviour correct? If it is, in a situation where there's > > only a UsernameToken (passwordType="PasswordText") is sent in the > > security header, why should one specify the callback handler at the > > service deployment? > > > > It's clear that the service impl can authenticate the UT as well, > > using the WSSecurityEngineResult vector from the msgContext, but why > > not authenticate at the Engine in the above instance? > > > > OR have I missed something obvious :-) ? > > > > Thanks in advance, > > Ruchith Fernando > > >
