Werner, thanks for the message. I've just been looking through the list archives and I'm still confused. If the callback handler passes the same password in plain text, I'm not sure why this causes a problem.
For UsernameToken, WSS4J only handles authentication if the user is using Digest passwords. If you're using username/password, you have to handle it in your handler or your service. As of now, the responsibility of the callback changes depending upon if you're using Digest or Plaintext which doesn't seem like a good thing. I realize that I'm late to this party, but it doesn't seem right to me and based on the notes on the list, it seems like I'm not the only one who was confused. I've searched through the mail archives (marc.theaimsgroup.com) back to 07/2005 but couldn't find anything on the discussion that led to the current design. The responsibilities of the classes are confusing to me (and probably others). I understand it now, but it's not intuitive. For Digest: PasswordCallbackHandler responsibility: retrieves the password for the user from a password store based on the user's identity UsernameTokenProcessor responsibility: validates the incoming password against the password retrieved by the callback handler and throws a security exception if they don't match Currently (as of 1.5.0) for Plaintext PasswordCallbackHandler responsibility: retrieves the password for the user from a password store based on the user's identity, and throws a WSSecurityException if the password doesn't match. UsernameTokenProcessor - does NOT validate the incoming password against the password retreived by the callback handler. No security exception is thrown if they don't match. I'm still not clear on why the responsibilities of these classes can't be similar for both scenarios. Brian On 5/9/06, Dittmann, Werner <[EMAIL PROTECTED]> wrote:
Sorry, brian, I confused it with a Timestamp topic. We had the password topic also as a JIRA issue (WSS-25). Here are the comments/e-mail. Regards, Werner <quotes> Kevin, yes you are right with respect to JAAS and the overall callback semantic. When we introduced this specific behaviour we explicitly stated that we deviate here from the JAAS meaning. This is mainly because the handler cannot check the password in every case because password type text is often used to transport password data transparently that is passed forward to the service (we had several discussions here on the list about that). Also the WSS spec allows to introduce own password type attributes. Thus we went on and said: well, the handler calls the callback method but with a specific usage type and the actual password type data. The callback implementation may now, based on the usage type and password type, decide what to do and may perform the check on its own and throw an exception if something is wrong. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: Kevin Fung (JIRA) [mailto:[EMAIL PROTECTED] > Gesendet: Donnerstag, 17. November 2005 15:17 > An: [email protected] > Betreff: [jira] Commented: (WSS-25) UsernameToken password is > not checked > > [ > http://issues.apache.org/jira/browse/WSS-25?page=comments#acti on_12357892 ] > > Kevin Fung commented on WSS-25: > ------------------------------- > > I used both password text and digest. Digest was checked, but > text was not. I see your point, but I think the convension of > JAAS CallbackHandler is to provide the password to the > PasswordCallback. The application (WSSecurityEngine in this > case) performs the validation, similar to the way that > password digest is handled. > > Regards, > Kevin > > > UsernameToken password is not checked > > ------------------------------------- > > > > Key: WSS-25 > > URL: http://issues.apache.org/jira/browse/WSS-25 > > Project: WSS4J > > Type: Bug > > Environment: Windows 2000, JDK 1.5.0_05-b05 > > Reporter: Kevin Fung > > Assignee: Davanum Srinivas > > > > > In the handleUsernameToken method in WSSecurityEngine > class, the password returned by the password handler is not > compared against the password/digest from the UsernameToken. > The result is that any password will be accepted. > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the > administrators: > http://issues.apache.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: > http://www.atlassian.com/software/jira > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
