You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by Lee Breisacher <LB...@seagullsoftware.com> on 2006/07/10 19:11:12 UTC
alternative password verification
I have a system configuration that doesn't seem to fit into the wss4j
password-verification mechanism. I'm on the server side and I do not
have direct access to passwords, so I cannot write a password
CallbackHandler that fills in the password for a given user id. Rather I
have programmatic access to a name/password-verification system -- I
pass in a name/password pair and it answers "valid" or "not valid" (I'm
oversimplifying, but that's the basic idea).
I've managed to make it work when I use PasswordText (plain text
passwords) because in that case the WSPasswordCallback object includes
the plain text password. But in the case where the password is digested,
the WSPasswordCallback object does not include the password (digested or
otherwise).
So, does anyone have a suggestion for how to best utilize wss4j in this
situation?
Thanks,
Lee
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: alternative password verification
Posted by Lee Breisacher <LB...@seagullsoftware.com>.
Ah - sorry, I'm sorta new to this and I had not really understood what
digested means. Now I've read up on it and I see that it is a one-way
operation. So yeah, I'm stuck with plain text (or it looks like I could
make up my own password type that would have some private two-way
encryption scheme).
Thanks,
Lee
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Tuesday, July 11, 2006 8:53 PM
> To: Lee Breisacher
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: alternative password verification
>
> IMHO it is not possible to use a "name/password-verification system"
> in the case of a digest password since we will never get
> access to the password.
>
> The way to authenticate the passwordDigest scenario is very
> specif, where the digest is calculated and compared with the
> value in the UsernameToken, using the password supplied by
> the callback handler.
>
> Also IMHO, in such a situation WSS4J _must_ not allow other
> handlers or services to access the actual password. And even
> if we do so what is the point of doing double authentication?
>
> Therefore simply we should only use a pwsswordDigest type
> UsernameToken IFF we have access to the password at the point
> of authentication. If not we have to use a plain text password.
>
> Thanks,
> Ruchith
>
> On 7/12/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> > This seems like the kind of thing that should be do-able.
> Can I submit
> > a bug report/feature request to support this style of
> authentication?
> > How active is wss4j development - what are the chances of
> this being
> > implemented?
> >
> > Thanks,
> >
> > Lee
> >
> > > -----Original Message-----
> > > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Sent: Tuesday, July 11, 2006 3:11 AM
> > > To: Lee Breisacher
> > > Cc: wss4j-dev@ws.apache.org
> > > Subject: Re: alternative password verification
> > >
> > > Hi Lee,
> > >
> > > IMHO you have to stick to plain text password. And to make it
> > > effective you will have to use a secure transport (HTTPS)
> or encrypt
> > > the UsernameToken header.
> > >
> > > WSS4J does not carryout any authentication in the case of
> the plain
> > > text password in a UsernameToken. It allows you you to
> authenticate
> > > the user using the mechanisms available as you described.
> This can
> > > be done by a handler after the WSDoAllReceiver or at the service.
> > >
> > > Thanks,
> > > Ruchith
> > >
> > > On 7/10/06, Lee Breisacher
> <LB...@seagullsoftware.com> wrote:
> > > > I have a system configuration that doesn't seem to fit into
> > > the wss4j
> > > > password-verification mechanism. I'm on the server side
> > > and I do not
> > > > have direct access to passwords, so I cannot write a password
> > > > CallbackHandler that fills in the password for a given user
> > > id. Rather
> > > > I have programmatic access to a name/password-verification
> > > system -- I
> > > > pass in a name/password pair and it answers "valid" or
> "not valid"
> > > > (I'm oversimplifying, but that's the basic idea).
> > > >
> > > > I've managed to make it work when I use PasswordText (plain text
> > > > passwords) because in that case the WSPasswordCallback
> > > object includes
> > > > the plain text password. But in the case where the password is
> > > > digested, the WSPasswordCallback object does not include
> > > the password
> > > > (digested or otherwise).
> > > >
> > > > So, does anyone have a suggestion for how to best
> utilize wss4j in
> > > > this situation?
> > > >
> > > > Thanks,
> > > >
> > > > Lee
> > > >
> > > >
> > >
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > www.ruchith.org
> > >
> > >
> >
>
>
> --
> www.ruchith.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: alternative password verification
Posted by Lee Breisacher <LB...@seagullsoftware.com>.
Ah - sorry, I'm sorta new to this and I had not really understood what
digested means. Now I've read up on it and I see that it is a one-way
operation. So yeah, I'm stuck with plain text (or it looks like I could
make up my own password type that would have some private two-way
encryption scheme).
Thanks,
Lee
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Tuesday, July 11, 2006 8:53 PM
> To: Lee Breisacher
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: alternative password verification
>
> IMHO it is not possible to use a "name/password-verification system"
> in the case of a digest password since we will never get
> access to the password.
>
> The way to authenticate the passwordDigest scenario is very
> specif, where the digest is calculated and compared with the
> value in the UsernameToken, using the password supplied by
> the callback handler.
>
> Also IMHO, in such a situation WSS4J _must_ not allow other
> handlers or services to access the actual password. And even
> if we do so what is the point of doing double authentication?
>
> Therefore simply we should only use a pwsswordDigest type
> UsernameToken IFF we have access to the password at the point
> of authentication. If not we have to use a plain text password.
>
> Thanks,
> Ruchith
>
> On 7/12/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> > This seems like the kind of thing that should be do-able.
> Can I submit
> > a bug report/feature request to support this style of
> authentication?
> > How active is wss4j development - what are the chances of
> this being
> > implemented?
> >
> > Thanks,
> >
> > Lee
> >
> > > -----Original Message-----
> > > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > > Sent: Tuesday, July 11, 2006 3:11 AM
> > > To: Lee Breisacher
> > > Cc: wss4j-dev@ws.apache.org
> > > Subject: Re: alternative password verification
> > >
> > > Hi Lee,
> > >
> > > IMHO you have to stick to plain text password. And to make it
> > > effective you will have to use a secure transport (HTTPS)
> or encrypt
> > > the UsernameToken header.
> > >
> > > WSS4J does not carryout any authentication in the case of
> the plain
> > > text password in a UsernameToken. It allows you you to
> authenticate
> > > the user using the mechanisms available as you described.
> This can
> > > be done by a handler after the WSDoAllReceiver or at the service.
> > >
> > > Thanks,
> > > Ruchith
> > >
> > > On 7/10/06, Lee Breisacher
> <LB...@seagullsoftware.com> wrote:
> > > > I have a system configuration that doesn't seem to fit into
> > > the wss4j
> > > > password-verification mechanism. I'm on the server side
> > > and I do not
> > > > have direct access to passwords, so I cannot write a password
> > > > CallbackHandler that fills in the password for a given user
> > > id. Rather
> > > > I have programmatic access to a name/password-verification
> > > system -- I
> > > > pass in a name/password pair and it answers "valid" or
> "not valid"
> > > > (I'm oversimplifying, but that's the basic idea).
> > > >
> > > > I've managed to make it work when I use PasswordText (plain text
> > > > passwords) because in that case the WSPasswordCallback
> > > object includes
> > > > the plain text password. But in the case where the password is
> > > > digested, the WSPasswordCallback object does not include
> > > the password
> > > > (digested or otherwise).
> > > >
> > > > So, does anyone have a suggestion for how to best
> utilize wss4j in
> > > > this situation?
> > > >
> > > > Thanks,
> > > >
> > > > Lee
> > > >
> > > >
> > >
> --------------------------------------------------------------------
> > > -
> > > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > www.ruchith.org
> > >
> > >
> >
>
>
> --
> www.ruchith.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: alternative password verification
Posted by Ruchith Fernando <ru...@gmail.com>.
IMHO it is not possible to use a "name/password-verification system"
in the case of a digest password since we will never get access to the
password.
The way to authenticate the passwordDigest scenario is very specif,
where the digest is calculated and compared with the value in the
UsernameToken, using the password supplied by the callback handler.
Also IMHO, in such a situation WSS4J _must_ not allow other handlers
or services to access the actual password. And even if we do so what
is the point of doing double authentication?
Therefore simply we should only use a pwsswordDigest type
UsernameToken IFF we have access to the password at the point of
authentication. If not we have to use a plain text password.
Thanks,
Ruchith
On 7/12/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> This seems like the kind of thing that should be do-able. Can I submit a
> bug report/feature request to support this style of authentication? How
> active is wss4j development - what are the chances of this being
> implemented?
>
> Thanks,
>
> Lee
>
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Sent: Tuesday, July 11, 2006 3:11 AM
> > To: Lee Breisacher
> > Cc: wss4j-dev@ws.apache.org
> > Subject: Re: alternative password verification
> >
> > Hi Lee,
> >
> > IMHO you have to stick to plain text password. And to make it
> > effective you will have to use a secure transport (HTTPS) or
> > encrypt the UsernameToken header.
> >
> > WSS4J does not carryout any authentication in the case of the
> > plain text password in a UsernameToken. It allows you you to
> > authenticate the user using the mechanisms available as you
> > described. This can be done by a handler after the
> > WSDoAllReceiver or at the service.
> >
> > Thanks,
> > Ruchith
> >
> > On 7/10/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> > > I have a system configuration that doesn't seem to fit into
> > the wss4j
> > > password-verification mechanism. I'm on the server side
> > and I do not
> > > have direct access to passwords, so I cannot write a password
> > > CallbackHandler that fills in the password for a given user
> > id. Rather
> > > I have programmatic access to a name/password-verification
> > system -- I
> > > pass in a name/password pair and it answers "valid" or "not valid"
> > > (I'm oversimplifying, but that's the basic idea).
> > >
> > > I've managed to make it work when I use PasswordText (plain text
> > > passwords) because in that case the WSPasswordCallback
> > object includes
> > > the plain text password. But in the case where the password is
> > > digested, the WSPasswordCallback object does not include
> > the password
> > > (digested or otherwise).
> > >
> > > So, does anyone have a suggestion for how to best utilize wss4j in
> > > this situation?
> > >
> > > Thanks,
> > >
> > > Lee
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > www.ruchith.org
> >
> >
>
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: alternative password verification
Posted by Ruchith Fernando <ru...@gmail.com>.
IMHO it is not possible to use a "name/password-verification system"
in the case of a digest password since we will never get access to the
password.
The way to authenticate the passwordDigest scenario is very specif,
where the digest is calculated and compared with the value in the
UsernameToken, using the password supplied by the callback handler.
Also IMHO, in such a situation WSS4J _must_ not allow other handlers
or services to access the actual password. And even if we do so what
is the point of doing double authentication?
Therefore simply we should only use a pwsswordDigest type
UsernameToken IFF we have access to the password at the point of
authentication. If not we have to use a plain text password.
Thanks,
Ruchith
On 7/12/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> This seems like the kind of thing that should be do-able. Can I submit a
> bug report/feature request to support this style of authentication? How
> active is wss4j development - what are the chances of this being
> implemented?
>
> Thanks,
>
> Lee
>
> > -----Original Message-----
> > From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Sent: Tuesday, July 11, 2006 3:11 AM
> > To: Lee Breisacher
> > Cc: wss4j-dev@ws.apache.org
> > Subject: Re: alternative password verification
> >
> > Hi Lee,
> >
> > IMHO you have to stick to plain text password. And to make it
> > effective you will have to use a secure transport (HTTPS) or
> > encrypt the UsernameToken header.
> >
> > WSS4J does not carryout any authentication in the case of the
> > plain text password in a UsernameToken. It allows you you to
> > authenticate the user using the mechanisms available as you
> > described. This can be done by a handler after the
> > WSDoAllReceiver or at the service.
> >
> > Thanks,
> > Ruchith
> >
> > On 7/10/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> > > I have a system configuration that doesn't seem to fit into
> > the wss4j
> > > password-verification mechanism. I'm on the server side
> > and I do not
> > > have direct access to passwords, so I cannot write a password
> > > CallbackHandler that fills in the password for a given user
> > id. Rather
> > > I have programmatic access to a name/password-verification
> > system -- I
> > > pass in a name/password pair and it answers "valid" or "not valid"
> > > (I'm oversimplifying, but that's the basic idea).
> > >
> > > I've managed to make it work when I use PasswordText (plain text
> > > passwords) because in that case the WSPasswordCallback
> > object includes
> > > the plain text password. But in the case where the password is
> > > digested, the WSPasswordCallback object does not include
> > the password
> > > (digested or otherwise).
> > >
> > > So, does anyone have a suggestion for how to best utilize wss4j in
> > > this situation?
> > >
> > > Thanks,
> > >
> > > Lee
> > >
> > >
> > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> > >
> > >
> >
> >
> > --
> > www.ruchith.org
> >
> >
>
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: alternative password verification
Posted by Lee Breisacher <LB...@seagullsoftware.com>.
This seems like the kind of thing that should be do-able. Can I submit a
bug report/feature request to support this style of authentication? How
active is wss4j development - what are the chances of this being
implemented?
Thanks,
Lee
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Tuesday, July 11, 2006 3:11 AM
> To: Lee Breisacher
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: alternative password verification
>
> Hi Lee,
>
> IMHO you have to stick to plain text password. And to make it
> effective you will have to use a secure transport (HTTPS) or
> encrypt the UsernameToken header.
>
> WSS4J does not carryout any authentication in the case of the
> plain text password in a UsernameToken. It allows you you to
> authenticate the user using the mechanisms available as you
> described. This can be done by a handler after the
> WSDoAllReceiver or at the service.
>
> Thanks,
> Ruchith
>
> On 7/10/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> > I have a system configuration that doesn't seem to fit into
> the wss4j
> > password-verification mechanism. I'm on the server side
> and I do not
> > have direct access to passwords, so I cannot write a password
> > CallbackHandler that fills in the password for a given user
> id. Rather
> > I have programmatic access to a name/password-verification
> system -- I
> > pass in a name/password pair and it answers "valid" or "not valid"
> > (I'm oversimplifying, but that's the basic idea).
> >
> > I've managed to make it work when I use PasswordText (plain text
> > passwords) because in that case the WSPasswordCallback
> object includes
> > the plain text password. But in the case where the password is
> > digested, the WSPasswordCallback object does not include
> the password
> > (digested or otherwise).
> >
> > So, does anyone have a suggestion for how to best utilize wss4j in
> > this situation?
> >
> > Thanks,
> >
> > Lee
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
>
>
> --
> www.ruchith.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: alternative password verification
Posted by Lee Breisacher <LB...@seagullsoftware.com>.
This seems like the kind of thing that should be do-able. Can I submit a
bug report/feature request to support this style of authentication? How
active is wss4j development - what are the chances of this being
implemented?
Thanks,
Lee
> -----Original Message-----
> From: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> Sent: Tuesday, July 11, 2006 3:11 AM
> To: Lee Breisacher
> Cc: wss4j-dev@ws.apache.org
> Subject: Re: alternative password verification
>
> Hi Lee,
>
> IMHO you have to stick to plain text password. And to make it
> effective you will have to use a secure transport (HTTPS) or
> encrypt the UsernameToken header.
>
> WSS4J does not carryout any authentication in the case of the
> plain text password in a UsernameToken. It allows you you to
> authenticate the user using the mechanisms available as you
> described. This can be done by a handler after the
> WSDoAllReceiver or at the service.
>
> Thanks,
> Ruchith
>
> On 7/10/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> > I have a system configuration that doesn't seem to fit into
> the wss4j
> > password-verification mechanism. I'm on the server side
> and I do not
> > have direct access to passwords, so I cannot write a password
> > CallbackHandler that fills in the password for a given user
> id. Rather
> > I have programmatic access to a name/password-verification
> system -- I
> > pass in a name/password pair and it answers "valid" or "not valid"
> > (I'm oversimplifying, but that's the basic idea).
> >
> > I've managed to make it work when I use PasswordText (plain text
> > passwords) because in that case the WSPasswordCallback
> object includes
> > the plain text password. But in the case where the password is
> > digested, the WSPasswordCallback object does not include
> the password
> > (digested or otherwise).
> >
> > So, does anyone have a suggestion for how to best utilize wss4j in
> > this situation?
> >
> > Thanks,
> >
> > Lee
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> > For additional commands, e-mail: wss4j-dev-help@ws.apache.org
> >
> >
>
>
> --
> www.ruchith.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: alternative password verification
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Lee,
IMHO you have to stick to plain text password. And to make it
effective you will have to use a secure transport (HTTPS) or encrypt
the UsernameToken header.
WSS4J does not carryout any authentication in the case of the plain
text password in a UsernameToken. It allows you you to authenticate
the user using the mechanisms available as you described. This can be
done by a handler after the WSDoAllReceiver or at the service.
Thanks,
Ruchith
On 7/10/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> I have a system configuration that doesn't seem to fit into the wss4j
> password-verification mechanism. I'm on the server side and I do not
> have direct access to passwords, so I cannot write a password
> CallbackHandler that fills in the password for a given user id. Rather I
> have programmatic access to a name/password-verification system -- I
> pass in a name/password pair and it answers "valid" or "not valid" (I'm
> oversimplifying, but that's the basic idea).
>
> I've managed to make it work when I use PasswordText (plain text
> passwords) because in that case the WSPasswordCallback object includes
> the plain text password. But in the case where the password is digested,
> the WSPasswordCallback object does not include the password (digested or
> otherwise).
>
> So, does anyone have a suggestion for how to best utilize wss4j in this
> situation?
>
> Thanks,
>
> Lee
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
Re: alternative password verification
Posted by Ruchith Fernando <ru...@gmail.com>.
Hi Lee,
IMHO you have to stick to plain text password. And to make it
effective you will have to use a secure transport (HTTPS) or encrypt
the UsernameToken header.
WSS4J does not carryout any authentication in the case of the plain
text password in a UsernameToken. It allows you you to authenticate
the user using the mechanisms available as you described. This can be
done by a handler after the WSDoAllReceiver or at the service.
Thanks,
Ruchith
On 7/10/06, Lee Breisacher <LB...@seagullsoftware.com> wrote:
> I have a system configuration that doesn't seem to fit into the wss4j
> password-verification mechanism. I'm on the server side and I do not
> have direct access to passwords, so I cannot write a password
> CallbackHandler that fills in the password for a given user id. Rather I
> have programmatic access to a name/password-verification system -- I
> pass in a name/password pair and it answers "valid" or "not valid" (I'm
> oversimplifying, but that's the basic idea).
>
> I've managed to make it work when I use PasswordText (plain text
> passwords) because in that case the WSPasswordCallback object includes
> the plain text password. But in the case where the password is digested,
> the WSPasswordCallback object does not include the password (digested or
> otherwise).
>
> So, does anyone have a suggestion for how to best utilize wss4j in this
> situation?
>
> Thanks,
>
> Lee
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
--
www.ruchith.org
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org