[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wss4j-dev
Subject:    Re: Plaintext Password
From:       "Brian Bonner" <bkbonner () gmail ! com>
Date:       2006-05-10 13:57:10
Message-ID: e0904ff40605100657n6d003104n1aca7cd59d92f4d0 () mail ! gmail ! com
[Download RAW message or body]

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 <werner.dittmann@siemens.com> 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:jira@apache.org]
> > Gesendet: Donnerstag, 17. November 2005 15:17
> > An: wss4j-dev@ws.apache.org
> > 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: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]