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:[EMAIL PROTECTED] > Sent: Tuesday, July 11, 2006 8:53 PM > To: Lee Breisacher > Cc: [email protected] > 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > > Sent: Tuesday, July 11, 2006 3:11 AM > > > To: Lee Breisacher > > > Cc: [email protected] > > > 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 > <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > -- > > > www.ruchith.org > > > > > > > > > > > -- > www.ruchith.org > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
