You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fx-dev@ws.apache.org by Davanum Srinivas <di...@yahoo.com> on 2004/08/31 09:23:45 UTC
Re: UsernameToken functionality in WSS4J
Forwarding email to the mailing list...
-- dims
--- "Eadie, Alex" <Al...@team.telstra.com> wrote:
> Hi Werner,
>
>
>
> We are trying use wss4j's UsernameToken functionality as a step up from
> simple http authentication in our JBoss based application.
>
>
>
> The implementation in WSSecurityEngine.handleUsernameToken() that is
> provided assumes that given a username from across the wire, the writer
> of the UsernameTokenCallBack can return the bonafide password. However
> in our case we cannot provide the bonafide password, we can only
> ascertain whether a username/password combination is valid. This is
> because the bonafide password is one-way hashed in our password
> database.
>
>
>
> However the implementation of handleUsernameToken() also assumes that
> the passwords sent across the wire are also one-way hashed. This
> implies that it is not possible to get the password that came across the
> wire back into clear text. Is this correct?
>
>
>
> If this is the case how did you see integration with an application
> server working? When neither the password coming across the wire nor
> the password available in the password database can be returned to clear
> text and hence compared to each other.
>
>
>
> Is there any way the implementation can be modified to accommodate our
> situation? This could be configurable using an additional parameter in
> the deployment XML?
>
>
>
> Best Regards
>
> Alex Eadie
>
>
>
>
>
> Developer
>
> Telstra IADev
>
> Ph (02) 8255 3154
>
> Level 8
>
> 400 George St
>
> Sydney
>
>
>
>
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: UsernameToken functionality in WSS4J
Posted by Ilias Bartolini <il...@studio.unibo.it>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
WSS4J should provide and support both clear password and hashed password.
The specification (page 9 line 169) indicates Type="#PasswordText" can be
"The actual password for the username, the password hash, or derived password
or S/KEY."
I think WSS4J must not provide transparent hash transformation if not
specified from the application otherwise all scenarios can't be supported.
Support for "#PasswordDigest", algoritm described at (page 8 line 113) can be
an optional feature of WSS4J.
Ciao,
Ilias
- --
/**
* Reply to: ilias.bartolini(at)studio.unibo.it
* ICQ# 42797710 - FeSToso n°143 - PGP Key-IDs:0x6A951A45
* http://www.brainetwork.net/homepage
* https://www.universibo.unibo.it
*/
On Tuesday 31 August 2004 16:54, Sanga Viswanathan wrote:
> I don't think, we can assume that the sender would send a hashed password.
> The sender might send it in plain text.
> The DB would store passwords in hashed form, and this hash could be a
> salted hash. The client really cannot generate the same hash without
> knowing the salt value.
> So the way the server would authenticate is to get the plaintext password
> form the Username Token and hash it (using the salt) and then compare it
> with the hashed value in the DB.
>
> Obviously this is not going to work with the current implementation of
> WSS4J. In my opinion WSS4J should not attempt to provide the authentication
> logic. Instead it should have a mechanism by which it delegates it to the
> underlying application.
>
> Thanks
> Sanga
>
> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> Sent: Tuesday, August 31, 2004 5:15 AM
> To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
> Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
> dims@yahoo.com
> Subject: Re: UsernameToken functionality in WSS4J
>
>
> Alex,
>
> I assume that the sender (client) shall send the username and the hashed
> password. If this assumption is correct then I would do the following:
>
> - set up UsernameToken with the parameter to send the password in
> clear (passwordType is PasswordText)
> - provide the username and the stringified hashed password to username
> token - define an additional action to encrypt the UsernameToken before it
> is sent
>
> At the server side decrypt, get the username and the hashed password and
> compare the hash sent and the hash stored in the DB.
>
> Please have a look at the interop scenario #2. Its a similar setup:
> Username and password are set up in clear text, then the whole
> UsernameToken gets encrypted. This obviously is more overhead as you need a
> server certificate that is published to all your clients (for simple
> encryption no certificate chain is necessary). The clients will use the
> servers public key the perform the actual encryption.
>
> With this setup you can also send the password in clear
> to the server and the server perfoms the hashing and compares this result
> with the values stored in DB.
>
> Hope this helps.
>
> Regards,
> Werner
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFBNJiq+CP4pmqVGkURAjPXAJ4wue/5ZoT7QvyzZMOChlVuYhPAxgCcDLoB
Xg2iC1xTQJk1TuhYvqKKlxI=
=j0c4
-----END PGP SIGNATURE-----
Re: UsernameToken functionality in WSS4J
Posted by David Keppler <dk...@mitre.org>.
See JIRA WSFX-34 with patches attached.
David Keppler
Davanum Srinivas wrote:
> +1 from me too. Can one of you submit a patch as described by Werner?
>
> thanks,
> dims
>
> On Tue, 31 Aug 2004 21:13:01 +0200, Werner Dittmann
> <we...@t-online.de> wrote:
>
>>All,
>>
>>sounds good. Anyhow, I would do this only if the password typ is "plain
>>Text", not the
>>hashed password type because the verification of the hashed password does
>>not only
>>include the password itself but also the nounce, timestamp. The verfication
>>of a hashed
>> password is well specified. This specification shall be supported by the
>>WSS4J library
>>functions.
>>
>>For plaintext passwords - the authentication can, and probably should go to
>>the
>>service / application.
>>
>>Regards,
>>Werner
>>
>>
>>
>>----- Original Message -----
>>From: "David Keppler" <dk...@mitre.org>
>>To: <di...@apache.org>
>>Cc: "Sanga Viswanathan" <sv...@adobe.com>; "Werner Dittmann"
>><we...@t-online.de>; "Eadie, Alex" <al...@team.telstra.com>;
>><fx...@ws.apache.org>; "Freeman, Adam D" <ad...@team.telstra.com>;
>>"Alt, Robert" <ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
>><fe...@team.telstra.com>; "Sahdeva, Sudeep"
>><su...@team.telstra.com>; <di...@yahoo.com>
>>Sent: Tuesday, August 31, 2004 8:10 PM
>>Subject: Re: UsernameToken functionality in WSS4J
>>
>>
>>>How about creating a new field in WSUsernameTokenPrincipal to hold the
>>>password string from the UsernameToken. Instead of doing the password
>>>callback and check in handleUsernameToken() in WSSecurityEngine, just
>>>have it copy the password string from the password string into the
>>>WSUsernameTokenPrincipal that is already created and put into the
>>>WSSecurityEngineResult. So now all the data from the UsernameToken can
>>>be accessed from the service, moving authentication logic outside of
>>
>>wss4j.
>>
>>>Overall the only changes would be these:
>>>- add another String field to WSUsernameTokenPrincipal
>>>- change constructor WSUsernameTokenPrincipal to take password string as
>>>well as user name
>>>- remove the password callback and password matching check from
>>>handleUsernameToken in WSSecurityEngine
>>>
>>>How's that sound?
>>>
>>>- David Keppler
>>>
>>>Davanum Srinivas wrote:
>>>
>>>>Sanga,
>>>>
>>>>Do you have a proposal (or better still a patch) on how to achieve this?
>>>>
>>>>thanks,
>>>>dims
>>>>
>>>>On Tue, 31 Aug 2004 07:54:30 -0700, Sanga Viswanathan
>>>><sv...@adobe.com> wrote:
>>>>
>>>>
>>>>>I don't think, we can assume that the sender would send a hashed
>>
>>password.
>>
>>>>>The sender might send it in plain text.
>>>>>The DB would store passwords in hashed form, and this hash could be a
>>
>>salted
>>
>>>>>hash. The client really cannot generate the same hash without knowing
>>
>>the
>>
>>>>>salt value.
>>>>>So the way the server would authenticate is to get the plaintext
>>
>>password
>>
>>>>>form the Username Token and hash it (using the salt) and then compare it
>>>>>with the hashed value in the DB.
>>>>>
>>>>>Obviously this is not going to work with the current implementation of
>>>>>WSS4J. In my opinion WSS4J should not attempt to provide the
>>
>>authentication
>>
>>>>>logic. Instead it should have a mechanism by which it delegates it to
>>
>>the
>>
>>>>>underlying application.
>>>>>
>>>>>Thanks
>>>>>Sanga
>>>>>
>>>>>
>>>>>
>>>>>-----Original Message-----
>>>>>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
>>>>>Sent: Tuesday, August 31, 2004 5:15 AM
>>>>>To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
>>>>>Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
>>>>>dims@yahoo.com
>>>>>Subject: Re: UsernameToken functionality in WSS4J
>>>>>
>>>>>Alex,
>>>>>
>>>>>I assume that the sender (client) shall send the username and the hashed
>>>>>password. If this assumption is correct then I would do the following:
>>>>>
>>>>>- set up UsernameToken with the parameter to send the password in
>>>>> clear (passwordType is PasswordText)
>>>>>- provide the username and the stringified hashed password to username
>>
>>token
>>
>>>>>- define an additional action to encrypt the UsernameToken before it is
>>
>>sent
>>
>>>>>At the server side decrypt, get the username and the hashed password and
>>>>>compare the hash sent and the hash stored in the DB.
>>>>>
>>>>>Please have a look at the interop scenario #2. Its a similar setup:
>>
>>Username
>>
>>>>>and password are set up in clear text, then the whole UsernameToken gets
>>>>>encrypted. This obviously is more overhead as you need a server
>>
>>certificate
>>
>>>>>that is published to all your clients (for simple encryption no
>>
>>certificate
>>
>>>>>chain is necessary). The clients will use the servers public key the
>>
>>perform
>>
>>>>>the actual encryption.
>>>>>
>>>>>With this setup you can also send the password in clear
>>>>>to the server and the server perfoms the hashing and compares this
>>
>>result
>>
>>>>>with the values stored in DB.
>>>>>
>>>>>Hope this helps.
>>>>>
>>>>>Regards,
>>>>>Werner
>>>>>
>>>>>----- Original Message -----
>>>>>From: "Davanum Srinivas" <di...@yahoo.com>
>>>>>To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
>>>>><we...@siemens.com>; <fx...@ws.apache.org>
>>>>>Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
>>>>><Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
>>>>><Fe...@team.telstra.com>; "Sahdeva, Sudeep"
>>>>><Su...@team.telstra.com>; <di...@yahoo.com>
>>>>>Sent: Tuesday, August 31, 2004 9:23 AM
>>>>>Subject: Re: UsernameToken functionality in WSS4J
>>>>>
>>>>>
>>>>>
>>>>>>Forwarding email to the mailing list...
>>>>>>
>>>>>>-- dims
>>>>>>
>>>>>>--- "Eadie, Alex" <Al...@team.telstra.com> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>>Hi Werner,
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>We are trying use wss4j's UsernameToken functionality as a step up
>>>>>>
>>>>>>>from simple http authentication in our JBoss based application.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>The implementation in WSSecurityEngine.handleUsernameToken() that is
>>>>>>>provided assumes that given a username from across the wire, the
>>
>>writer
>>
>>>>>>>of the UsernameTokenCallBack can return the bonafide password.
>>
>>However
>>
>>>>>>>in our case we cannot provide the bonafide password, we can only
>>>>>>>ascertain whether a username/password combination is valid. This is
>>>>>>>because the bonafide password is one-way hashed in our password
>>>>>>>database.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>However the implementation of handleUsernameToken() also assumes that
>>>>>>>the passwords sent across the wire are also one-way hashed. This
>>>>>>>implies that it is not possible to get the password that came across
>>
>>the
>>
>>>>>>>wire back into clear text. Is this correct?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>If this is the case how did you see integration with an application
>>>>>>>server working? When neither the password coming across the wire
>>>>>>>nor the password available in the password database can be returned
>>>>>>>to clear text and hence compared to each other.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Is there any way the implementation can be modified to accommodate
>>>>>>>our situation? This could be configurable using an additional
>>>>>>>parameter in the deployment XML?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Best Regards
>>>>>>>
>>>>>>>Alex Eadie
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>Developer
>>>>>>>
>>>>>>>Telstra IADev
>>>>>>>
>>>>>>>Ph (02) 8255 3154
>>>>>>>
>>>>>>>Level 8
>>>>>>>
>>>>>>>400 George St
>>>>>>>
>>>>>>>Sydney
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>=====
>>>>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>>>>>
>>>>>>__________________________________________________
>>>>>>Do You Yahoo!?
>>>>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>>>>http://mail.yahoo.com
>>>>>
>>>>>
>>>>
>>
>
>
Re: UsernameToken functionality in WSS4J
Posted by Davanum Srinivas <da...@gmail.com>.
+1 from me too. Can one of you submit a patch as described by Werner?
thanks,
dims
On Tue, 31 Aug 2004 21:13:01 +0200, Werner Dittmann
<we...@t-online.de> wrote:
> All,
>
> sounds good. Anyhow, I would do this only if the password typ is "plain
> Text", not the
> hashed password type because the verification of the hashed password does
> not only
> include the password itself but also the nounce, timestamp. The verfication
> of a hashed
> password is well specified. This specification shall be supported by the
> WSS4J library
> functions.
>
> For plaintext passwords - the authentication can, and probably should go to
> the
> service / application.
>
> Regards,
> Werner
>
>
>
> ----- Original Message -----
> From: "David Keppler" <dk...@mitre.org>
> To: <di...@apache.org>
> Cc: "Sanga Viswanathan" <sv...@adobe.com>; "Werner Dittmann"
> <we...@t-online.de>; "Eadie, Alex" <al...@team.telstra.com>;
> <fx...@ws.apache.org>; "Freeman, Adam D" <ad...@team.telstra.com>;
> "Alt, Robert" <ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
> <fe...@team.telstra.com>; "Sahdeva, Sudeep"
> <su...@team.telstra.com>; <di...@yahoo.com>
> Sent: Tuesday, August 31, 2004 8:10 PM
> Subject: Re: UsernameToken functionality in WSS4J
>
> > How about creating a new field in WSUsernameTokenPrincipal to hold the
> > password string from the UsernameToken. Instead of doing the password
> > callback and check in handleUsernameToken() in WSSecurityEngine, just
> > have it copy the password string from the password string into the
> > WSUsernameTokenPrincipal that is already created and put into the
> > WSSecurityEngineResult. So now all the data from the UsernameToken can
> > be accessed from the service, moving authentication logic outside of
> wss4j.
> >
> > Overall the only changes would be these:
> > - add another String field to WSUsernameTokenPrincipal
> > - change constructor WSUsernameTokenPrincipal to take password string as
> > well as user name
> > - remove the password callback and password matching check from
> > handleUsernameToken in WSSecurityEngine
> >
> > How's that sound?
> >
> > - David Keppler
> >
> > Davanum Srinivas wrote:
> > > Sanga,
> > >
> > > Do you have a proposal (or better still a patch) on how to achieve this?
> > >
> > > thanks,
> > > dims
> > >
> > > On Tue, 31 Aug 2004 07:54:30 -0700, Sanga Viswanathan
> > > <sv...@adobe.com> wrote:
> > >
> > >>I don't think, we can assume that the sender would send a hashed
> password.
> > >>The sender might send it in plain text.
> > >>The DB would store passwords in hashed form, and this hash could be a
> salted
> > >>hash. The client really cannot generate the same hash without knowing
> the
> > >>salt value.
> > >> So the way the server would authenticate is to get the plaintext
> password
> > >>form the Username Token and hash it (using the salt) and then compare it
> > >>with the hashed value in the DB.
> > >>
> > >>Obviously this is not going to work with the current implementation of
> > >>WSS4J. In my opinion WSS4J should not attempt to provide the
> authentication
> > >>logic. Instead it should have a mechanism by which it delegates it to
> the
> > >>underlying application.
> > >>
> > >>Thanks
> > >>Sanga
> > >>
> > >>
> > >>
> > >>-----Original Message-----
> > >>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> > >>Sent: Tuesday, August 31, 2004 5:15 AM
> > >>To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
> > >>Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
> > >>dims@yahoo.com
> > >>Subject: Re: UsernameToken functionality in WSS4J
> > >>
> > >>Alex,
> > >>
> > >>I assume that the sender (client) shall send the username and the hashed
> > >>password. If this assumption is correct then I would do the following:
> > >>
> > >>- set up UsernameToken with the parameter to send the password in
> > >> clear (passwordType is PasswordText)
> > >>- provide the username and the stringified hashed password to username
> token
> > >>- define an additional action to encrypt the UsernameToken before it is
> sent
> > >>
> > >>At the server side decrypt, get the username and the hashed password and
> > >>compare the hash sent and the hash stored in the DB.
> > >>
> > >>Please have a look at the interop scenario #2. Its a similar setup:
> Username
> > >>and password are set up in clear text, then the whole UsernameToken gets
> > >>encrypted. This obviously is more overhead as you need a server
> certificate
> > >>that is published to all your clients (for simple encryption no
> certificate
> > >>chain is necessary). The clients will use the servers public key the
> perform
> > >>the actual encryption.
> > >>
> > >>With this setup you can also send the password in clear
> > >>to the server and the server perfoms the hashing and compares this
> result
> > >>with the values stored in DB.
> > >>
> > >>Hope this helps.
> > >>
> > >>Regards,
> > >>Werner
> > >>
> > >>----- Original Message -----
> > >>From: "Davanum Srinivas" <di...@yahoo.com>
> > >>To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
> > >><we...@siemens.com>; <fx...@ws.apache.org>
> > >>Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
> > >><Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
> > >><Fe...@team.telstra.com>; "Sahdeva, Sudeep"
> > >><Su...@team.telstra.com>; <di...@yahoo.com>
> > >>Sent: Tuesday, August 31, 2004 9:23 AM
> > >>Subject: Re: UsernameToken functionality in WSS4J
> > >>
> > >>
> > >>>Forwarding email to the mailing list...
> > >>>
> > >>>-- dims
> > >>>
> > >>>--- "Eadie, Alex" <Al...@team.telstra.com> wrote:
> > >>>
> > >>>
> > >>>>Hi Werner,
> > >>>>
> > >>>>
> > >>>>
> > >>>>We are trying use wss4j's UsernameToken functionality as a step up
> > >>>>from simple http authentication in our JBoss based application.
> > >>>>
> > >>>>
> > >>>>
> > >>>>The implementation in WSSecurityEngine.handleUsernameToken() that is
> > >>>>provided assumes that given a username from across the wire, the
> writer
> > >>>>of the UsernameTokenCallBack can return the bonafide password.
> However
> > >>>>in our case we cannot provide the bonafide password, we can only
> > >>>>ascertain whether a username/password combination is valid. This is
> > >>>>because the bonafide password is one-way hashed in our password
> > >>>>database.
> > >>>>
> > >>>>
> > >>>>
> > >>>>However the implementation of handleUsernameToken() also assumes that
> > >>>>the passwords sent across the wire are also one-way hashed. This
> > >>>>implies that it is not possible to get the password that came across
> the
> > >>>>wire back into clear text. Is this correct?
> > >>>>
> > >>>>
> > >>>>
> > >>>>If this is the case how did you see integration with an application
> > >>>>server working? When neither the password coming across the wire
> > >>>>nor the password available in the password database can be returned
> > >>>>to clear text and hence compared to each other.
> > >>>>
> > >>>>
> > >>>>
> > >>>>Is there any way the implementation can be modified to accommodate
> > >>>>our situation? This could be configurable using an additional
> > >>>>parameter in the deployment XML?
> > >>>>
> > >>>>
> > >>>>
> > >>>>Best Regards
> > >>>>
> > >>>>Alex Eadie
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>Developer
> > >>>>
> > >>>>Telstra IADev
> > >>>>
> > >>>>Ph (02) 8255 3154
> > >>>>
> > >>>>Level 8
> > >>>>
> > >>>>400 George St
> > >>>>
> > >>>>Sydney
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>
> > >>>
> > >>>=====
> > >>>Davanum Srinivas - http://webservices.apache.org/~dims/
> > >>>
> > >>>__________________________________________________
> > >>>Do You Yahoo!?
> > >>>Tired of spam? Yahoo! Mail has the best spam protection around
> > >>>http://mail.yahoo.com
> > >>
> > >>
> > >
> > >
> >
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: UsernameToken functionality in WSS4J
Posted by Werner Dittmann <We...@t-online.de>.
All,
sounds good. Anyhow, I would do this only if the password typ is "plain
Text", not the
hashed password type because the verification of the hashed password does
not only
include the password itself but also the nounce, timestamp. The verfication
of a hashed
password is well specified. This specification shall be supported by the
WSS4J library
functions.
For plaintext passwords - the authentication can, and probably should go to
the
service / application.
Regards,
Werner
----- Original Message -----
From: "David Keppler" <dk...@mitre.org>
To: <di...@apache.org>
Cc: "Sanga Viswanathan" <sv...@adobe.com>; "Werner Dittmann"
<we...@t-online.de>; "Eadie, Alex" <al...@team.telstra.com>;
<fx...@ws.apache.org>; "Freeman, Adam D" <ad...@team.telstra.com>;
"Alt, Robert" <ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
<fe...@team.telstra.com>; "Sahdeva, Sudeep"
<su...@team.telstra.com>; <di...@yahoo.com>
Sent: Tuesday, August 31, 2004 8:10 PM
Subject: Re: UsernameToken functionality in WSS4J
> How about creating a new field in WSUsernameTokenPrincipal to hold the
> password string from the UsernameToken. Instead of doing the password
> callback and check in handleUsernameToken() in WSSecurityEngine, just
> have it copy the password string from the password string into the
> WSUsernameTokenPrincipal that is already created and put into the
> WSSecurityEngineResult. So now all the data from the UsernameToken can
> be accessed from the service, moving authentication logic outside of
wss4j.
>
> Overall the only changes would be these:
> - add another String field to WSUsernameTokenPrincipal
> - change constructor WSUsernameTokenPrincipal to take password string as
> well as user name
> - remove the password callback and password matching check from
> handleUsernameToken in WSSecurityEngine
>
> How's that sound?
>
> - David Keppler
>
> Davanum Srinivas wrote:
> > Sanga,
> >
> > Do you have a proposal (or better still a patch) on how to achieve this?
> >
> > thanks,
> > dims
> >
> > On Tue, 31 Aug 2004 07:54:30 -0700, Sanga Viswanathan
> > <sv...@adobe.com> wrote:
> >
> >>I don't think, we can assume that the sender would send a hashed
password.
> >>The sender might send it in plain text.
> >>The DB would store passwords in hashed form, and this hash could be a
salted
> >>hash. The client really cannot generate the same hash without knowing
the
> >>salt value.
> >> So the way the server would authenticate is to get the plaintext
password
> >>form the Username Token and hash it (using the salt) and then compare it
> >>with the hashed value in the DB.
> >>
> >>Obviously this is not going to work with the current implementation of
> >>WSS4J. In my opinion WSS4J should not attempt to provide the
authentication
> >>logic. Instead it should have a mechanism by which it delegates it to
the
> >>underlying application.
> >>
> >>Thanks
> >>Sanga
> >>
> >>
> >>
> >>-----Original Message-----
> >>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> >>Sent: Tuesday, August 31, 2004 5:15 AM
> >>To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
> >>Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
> >>dims@yahoo.com
> >>Subject: Re: UsernameToken functionality in WSS4J
> >>
> >>Alex,
> >>
> >>I assume that the sender (client) shall send the username and the hashed
> >>password. If this assumption is correct then I would do the following:
> >>
> >>- set up UsernameToken with the parameter to send the password in
> >> clear (passwordType is PasswordText)
> >>- provide the username and the stringified hashed password to username
token
> >>- define an additional action to encrypt the UsernameToken before it is
sent
> >>
> >>At the server side decrypt, get the username and the hashed password and
> >>compare the hash sent and the hash stored in the DB.
> >>
> >>Please have a look at the interop scenario #2. Its a similar setup:
Username
> >>and password are set up in clear text, then the whole UsernameToken gets
> >>encrypted. This obviously is more overhead as you need a server
certificate
> >>that is published to all your clients (for simple encryption no
certificate
> >>chain is necessary). The clients will use the servers public key the
perform
> >>the actual encryption.
> >>
> >>With this setup you can also send the password in clear
> >>to the server and the server perfoms the hashing and compares this
result
> >>with the values stored in DB.
> >>
> >>Hope this helps.
> >>
> >>Regards,
> >>Werner
> >>
> >>----- Original Message -----
> >>From: "Davanum Srinivas" <di...@yahoo.com>
> >>To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
> >><we...@siemens.com>; <fx...@ws.apache.org>
> >>Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
> >><Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
> >><Fe...@team.telstra.com>; "Sahdeva, Sudeep"
> >><Su...@team.telstra.com>; <di...@yahoo.com>
> >>Sent: Tuesday, August 31, 2004 9:23 AM
> >>Subject: Re: UsernameToken functionality in WSS4J
> >>
> >>
> >>>Forwarding email to the mailing list...
> >>>
> >>>-- dims
> >>>
> >>>--- "Eadie, Alex" <Al...@team.telstra.com> wrote:
> >>>
> >>>
> >>>>Hi Werner,
> >>>>
> >>>>
> >>>>
> >>>>We are trying use wss4j's UsernameToken functionality as a step up
> >>>>from simple http authentication in our JBoss based application.
> >>>>
> >>>>
> >>>>
> >>>>The implementation in WSSecurityEngine.handleUsernameToken() that is
> >>>>provided assumes that given a username from across the wire, the
writer
> >>>>of the UsernameTokenCallBack can return the bonafide password.
However
> >>>>in our case we cannot provide the bonafide password, we can only
> >>>>ascertain whether a username/password combination is valid. This is
> >>>>because the bonafide password is one-way hashed in our password
> >>>>database.
> >>>>
> >>>>
> >>>>
> >>>>However the implementation of handleUsernameToken() also assumes that
> >>>>the passwords sent across the wire are also one-way hashed. This
> >>>>implies that it is not possible to get the password that came across
the
> >>>>wire back into clear text. Is this correct?
> >>>>
> >>>>
> >>>>
> >>>>If this is the case how did you see integration with an application
> >>>>server working? When neither the password coming across the wire
> >>>>nor the password available in the password database can be returned
> >>>>to clear text and hence compared to each other.
> >>>>
> >>>>
> >>>>
> >>>>Is there any way the implementation can be modified to accommodate
> >>>>our situation? This could be configurable using an additional
> >>>>parameter in the deployment XML?
> >>>>
> >>>>
> >>>>
> >>>>Best Regards
> >>>>
> >>>>Alex Eadie
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>Developer
> >>>>
> >>>>Telstra IADev
> >>>>
> >>>>Ph (02) 8255 3154
> >>>>
> >>>>Level 8
> >>>>
> >>>>400 George St
> >>>>
> >>>>Sydney
> >>>>
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>>=====
> >>>Davanum Srinivas - http://webservices.apache.org/~dims/
> >>>
> >>>__________________________________________________
> >>>Do You Yahoo!?
> >>>Tired of spam? Yahoo! Mail has the best spam protection around
> >>>http://mail.yahoo.com
> >>
> >>
> >
> >
>
Re: UsernameToken functionality in WSS4J
Posted by David Keppler <dk...@mitre.org>.
How about creating a new field in WSUsernameTokenPrincipal to hold the
password string from the UsernameToken. Instead of doing the password
callback and check in handleUsernameToken() in WSSecurityEngine, just
have it copy the password string from the password string into the
WSUsernameTokenPrincipal that is already created and put into the
WSSecurityEngineResult. So now all the data from the UsernameToken can
be accessed from the service, moving authentication logic outside of wss4j.
Overall the only changes would be these:
- add another String field to WSUsernameTokenPrincipal
- change constructor WSUsernameTokenPrincipal to take password string as
well as user name
- remove the password callback and password matching check from
handleUsernameToken in WSSecurityEngine
How's that sound?
- David Keppler
Davanum Srinivas wrote:
> Sanga,
>
> Do you have a proposal (or better still a patch) on how to achieve this?
>
> thanks,
> dims
>
> On Tue, 31 Aug 2004 07:54:30 -0700, Sanga Viswanathan
> <sv...@adobe.com> wrote:
>
>>I don't think, we can assume that the sender would send a hashed password.
>>The sender might send it in plain text.
>>The DB would store passwords in hashed form, and this hash could be a salted
>>hash. The client really cannot generate the same hash without knowing the
>>salt value.
>> So the way the server would authenticate is to get the plaintext password
>>form the Username Token and hash it (using the salt) and then compare it
>>with the hashed value in the DB.
>>
>>Obviously this is not going to work with the current implementation of
>>WSS4J. In my opinion WSS4J should not attempt to provide the authentication
>>logic. Instead it should have a mechanism by which it delegates it to the
>>underlying application.
>>
>>Thanks
>>Sanga
>>
>>
>>
>>-----Original Message-----
>>From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
>>Sent: Tuesday, August 31, 2004 5:15 AM
>>To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
>>Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
>>dims@yahoo.com
>>Subject: Re: UsernameToken functionality in WSS4J
>>
>>Alex,
>>
>>I assume that the sender (client) shall send the username and the hashed
>>password. If this assumption is correct then I would do the following:
>>
>>- set up UsernameToken with the parameter to send the password in
>> clear (passwordType is PasswordText)
>>- provide the username and the stringified hashed password to username token
>>- define an additional action to encrypt the UsernameToken before it is sent
>>
>>At the server side decrypt, get the username and the hashed password and
>>compare the hash sent and the hash stored in the DB.
>>
>>Please have a look at the interop scenario #2. Its a similar setup: Username
>>and password are set up in clear text, then the whole UsernameToken gets
>>encrypted. This obviously is more overhead as you need a server certificate
>>that is published to all your clients (for simple encryption no certificate
>>chain is necessary). The clients will use the servers public key the perform
>>the actual encryption.
>>
>>With this setup you can also send the password in clear
>>to the server and the server perfoms the hashing and compares this result
>>with the values stored in DB.
>>
>>Hope this helps.
>>
>>Regards,
>>Werner
>>
>>----- Original Message -----
>>From: "Davanum Srinivas" <di...@yahoo.com>
>>To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
>><we...@siemens.com>; <fx...@ws.apache.org>
>>Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
>><Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
>><Fe...@team.telstra.com>; "Sahdeva, Sudeep"
>><Su...@team.telstra.com>; <di...@yahoo.com>
>>Sent: Tuesday, August 31, 2004 9:23 AM
>>Subject: Re: UsernameToken functionality in WSS4J
>>
>>
>>>Forwarding email to the mailing list...
>>>
>>>-- dims
>>>
>>>--- "Eadie, Alex" <Al...@team.telstra.com> wrote:
>>>
>>>
>>>>Hi Werner,
>>>>
>>>>
>>>>
>>>>We are trying use wss4j's UsernameToken functionality as a step up
>>>>from simple http authentication in our JBoss based application.
>>>>
>>>>
>>>>
>>>>The implementation in WSSecurityEngine.handleUsernameToken() that is
>>>>provided assumes that given a username from across the wire, the writer
>>>>of the UsernameTokenCallBack can return the bonafide password. However
>>>>in our case we cannot provide the bonafide password, we can only
>>>>ascertain whether a username/password combination is valid. This is
>>>>because the bonafide password is one-way hashed in our password
>>>>database.
>>>>
>>>>
>>>>
>>>>However the implementation of handleUsernameToken() also assumes that
>>>>the passwords sent across the wire are also one-way hashed. This
>>>>implies that it is not possible to get the password that came across the
>>>>wire back into clear text. Is this correct?
>>>>
>>>>
>>>>
>>>>If this is the case how did you see integration with an application
>>>>server working? When neither the password coming across the wire
>>>>nor the password available in the password database can be returned
>>>>to clear text and hence compared to each other.
>>>>
>>>>
>>>>
>>>>Is there any way the implementation can be modified to accommodate
>>>>our situation? This could be configurable using an additional
>>>>parameter in the deployment XML?
>>>>
>>>>
>>>>
>>>>Best Regards
>>>>
>>>>Alex Eadie
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>Developer
>>>>
>>>>Telstra IADev
>>>>
>>>>Ph (02) 8255 3154
>>>>
>>>>Level 8
>>>>
>>>>400 George St
>>>>
>>>>Sydney
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>=====
>>>Davanum Srinivas - http://webservices.apache.org/~dims/
>>>
>>>__________________________________________________
>>>Do You Yahoo!?
>>>Tired of spam? Yahoo! Mail has the best spam protection around
>>>http://mail.yahoo.com
>>
>>
>
>
Re: UsernameToken functionality in WSS4J
Posted by Davanum Srinivas <da...@gmail.com>.
Sanga,
Do you have a proposal (or better still a patch) on how to achieve this?
thanks,
dims
On Tue, 31 Aug 2004 07:54:30 -0700, Sanga Viswanathan
<sv...@adobe.com> wrote:
> I don't think, we can assume that the sender would send a hashed password.
> The sender might send it in plain text.
> The DB would store passwords in hashed form, and this hash could be a salted
> hash. The client really cannot generate the same hash without knowing the
> salt value.
> So the way the server would authenticate is to get the plaintext password
> form the Username Token and hash it (using the salt) and then compare it
> with the hashed value in the DB.
>
> Obviously this is not going to work with the current implementation of
> WSS4J. In my opinion WSS4J should not attempt to provide the authentication
> logic. Instead it should have a mechanism by which it delegates it to the
> underlying application.
>
> Thanks
> Sanga
>
>
>
> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
> Sent: Tuesday, August 31, 2004 5:15 AM
> To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
> Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
> dims@yahoo.com
> Subject: Re: UsernameToken functionality in WSS4J
>
> Alex,
>
> I assume that the sender (client) shall send the username and the hashed
> password. If this assumption is correct then I would do the following:
>
> - set up UsernameToken with the parameter to send the password in
> clear (passwordType is PasswordText)
> - provide the username and the stringified hashed password to username token
> - define an additional action to encrypt the UsernameToken before it is sent
>
> At the server side decrypt, get the username and the hashed password and
> compare the hash sent and the hash stored in the DB.
>
> Please have a look at the interop scenario #2. Its a similar setup: Username
> and password are set up in clear text, then the whole UsernameToken gets
> encrypted. This obviously is more overhead as you need a server certificate
> that is published to all your clients (for simple encryption no certificate
> chain is necessary). The clients will use the servers public key the perform
> the actual encryption.
>
> With this setup you can also send the password in clear
> to the server and the server perfoms the hashing and compares this result
> with the values stored in DB.
>
> Hope this helps.
>
> Regards,
> Werner
>
> ----- Original Message -----
> From: "Davanum Srinivas" <di...@yahoo.com>
> To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
> <we...@siemens.com>; <fx...@ws.apache.org>
> Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
> <Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
> <Fe...@team.telstra.com>; "Sahdeva, Sudeep"
> <Su...@team.telstra.com>; <di...@yahoo.com>
> Sent: Tuesday, August 31, 2004 9:23 AM
> Subject: Re: UsernameToken functionality in WSS4J
>
> > Forwarding email to the mailing list...
> >
> > -- dims
> >
> > --- "Eadie, Alex" <Al...@team.telstra.com> wrote:
> >
> > > Hi Werner,
> > >
> > >
> > >
> > > We are trying use wss4j's UsernameToken functionality as a step up
> > > from simple http authentication in our JBoss based application.
> > >
> > >
> > >
> > > The implementation in WSSecurityEngine.handleUsernameToken() that is
> > > provided assumes that given a username from across the wire, the writer
> > > of the UsernameTokenCallBack can return the bonafide password. However
> > > in our case we cannot provide the bonafide password, we can only
> > > ascertain whether a username/password combination is valid. This is
> > > because the bonafide password is one-way hashed in our password
> > > database.
> > >
> > >
> > >
> > > However the implementation of handleUsernameToken() also assumes that
> > > the passwords sent across the wire are also one-way hashed. This
> > > implies that it is not possible to get the password that came across the
> > > wire back into clear text. Is this correct?
> > >
> > >
> > >
> > > If this is the case how did you see integration with an application
> > > server working? When neither the password coming across the wire
> > > nor the password available in the password database can be returned
> > > to clear text and hence compared to each other.
> > >
> > >
> > >
> > > Is there any way the implementation can be modified to accommodate
> > > our situation? This could be configurable using an additional
> > > parameter in the deployment XML?
> > >
> > >
> > >
> > > Best Regards
> > >
> > > Alex Eadie
> > >
> > >
> > >
> > >
> > >
> > > Developer
> > >
> > > Telstra IADev
> > >
> > > Ph (02) 8255 3154
> > >
> > > Level 8
> > >
> > > 400 George St
> > >
> > > Sydney
> > >
> > >
> > >
> > >
> >
> >
> > =====
> > Davanum Srinivas - http://webservices.apache.org/~dims/
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam protection around
> > http://mail.yahoo.com
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
RE: UsernameToken functionality in WSS4J
Posted by Sanga Viswanathan <sv...@adobe.com>.
I don't think, we can assume that the sender would send a hashed password.
The sender might send it in plain text.
The DB would store passwords in hashed form, and this hash could be a salted
hash. The client really cannot generate the same hash without knowing the
salt value.
So the way the server would authenticate is to get the plaintext password
form the Username Token and hash it (using the salt) and then compare it
with the hashed value in the DB.
Obviously this is not going to work with the current implementation of
WSS4J. In my opinion WSS4J should not attempt to provide the authentication
logic. Instead it should have a mechanism by which it delegates it to the
underlying application.
Thanks
Sanga
-----Original Message-----
From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de]
Sent: Tuesday, August 31, 2004 5:15 AM
To: davanum@gmail.com; Eadie, Alex; fx-dev@ws.apache.org
Cc: Freeman, Adam D; Alt, Robert; Hajdarpasic, Ferhat; Sahdeva, Sudeep;
dims@yahoo.com
Subject: Re: UsernameToken functionality in WSS4J
Alex,
I assume that the sender (client) shall send the username and the hashed
password. If this assumption is correct then I would do the following:
- set up UsernameToken with the parameter to send the password in
clear (passwordType is PasswordText)
- provide the username and the stringified hashed password to username token
- define an additional action to encrypt the UsernameToken before it is sent
At the server side decrypt, get the username and the hashed password and
compare the hash sent and the hash stored in the DB.
Please have a look at the interop scenario #2. Its a similar setup: Username
and password are set up in clear text, then the whole UsernameToken gets
encrypted. This obviously is more overhead as you need a server certificate
that is published to all your clients (for simple encryption no certificate
chain is necessary). The clients will use the servers public key the perform
the actual encryption.
With this setup you can also send the password in clear
to the server and the server perfoms the hashing and compares this result
with the values stored in DB.
Hope this helps.
Regards,
Werner
----- Original Message -----
From: "Davanum Srinivas" <di...@yahoo.com>
To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
<we...@siemens.com>; <fx...@ws.apache.org>
Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
<Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
<Fe...@team.telstra.com>; "Sahdeva, Sudeep"
<Su...@team.telstra.com>; <di...@yahoo.com>
Sent: Tuesday, August 31, 2004 9:23 AM
Subject: Re: UsernameToken functionality in WSS4J
> Forwarding email to the mailing list...
>
> -- dims
>
> --- "Eadie, Alex" <Al...@team.telstra.com> wrote:
>
> > Hi Werner,
> >
> >
> >
> > We are trying use wss4j's UsernameToken functionality as a step up
> > from simple http authentication in our JBoss based application.
> >
> >
> >
> > The implementation in WSSecurityEngine.handleUsernameToken() that is
> > provided assumes that given a username from across the wire, the writer
> > of the UsernameTokenCallBack can return the bonafide password. However
> > in our case we cannot provide the bonafide password, we can only
> > ascertain whether a username/password combination is valid. This is
> > because the bonafide password is one-way hashed in our password
> > database.
> >
> >
> >
> > However the implementation of handleUsernameToken() also assumes that
> > the passwords sent across the wire are also one-way hashed. This
> > implies that it is not possible to get the password that came across the
> > wire back into clear text. Is this correct?
> >
> >
> >
> > If this is the case how did you see integration with an application
> > server working? When neither the password coming across the wire
> > nor the password available in the password database can be returned
> > to clear text and hence compared to each other.
> >
> >
> >
> > Is there any way the implementation can be modified to accommodate
> > our situation? This could be configurable using an additional
> > parameter in the deployment XML?
> >
> >
> >
> > Best Regards
> >
> > Alex Eadie
> >
> >
> >
> >
> >
> > Developer
> >
> > Telstra IADev
> >
> > Ph (02) 8255 3154
> >
> > Level 8
> >
> > 400 George St
> >
> > Sydney
> >
> >
> >
> >
>
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
Re: UsernameToken functionality in WSS4J
Posted by Werner Dittmann <We...@t-online.de>.
Alex,
I assume that the sender (client) shall send the username and the hashed
password.
If this assumption is correct then I would do the following:
- set up UsernameToken with the parameter to send the password in
clear (passwordType is PasswordText)
- provide the username and the stringified hashed password to username token
- define an additional action to encrypt the UsernameToken before it is sent
At the server side decrypt, get the username and the hashed password and
compare the hash sent and the hash stored in the DB.
Please have a look at the interop scenario #2. Its a similar setup:
Username and password are set up in clear text, then the whole
UsernameToken gets encrypted. This obviously is more overhead
as you need a server certificate that is published to all your clients
(for simple encryption no certificate chain is necessary). The
clients will use the servers public key the perform the actual
encryption.
With this setup you can also send the password in clear
to the server and the server perfoms the hashing and compares
this result with the values stored in DB.
Hope this helps.
Regards,
Werner
----- Original Message -----
From: "Davanum Srinivas" <di...@yahoo.com>
To: "Eadie, Alex" <Al...@team.telstra.com>; "Dittmann Werner"
<we...@siemens.com>; <fx...@ws.apache.org>
Cc: "Freeman, Adam D" <Ad...@team.telstra.com>; "Alt, Robert"
<Ro...@team.telstra.com>; "Hajdarpasic, Ferhat"
<Fe...@team.telstra.com>; "Sahdeva, Sudeep"
<Su...@team.telstra.com>; <di...@yahoo.com>
Sent: Tuesday, August 31, 2004 9:23 AM
Subject: Re: UsernameToken functionality in WSS4J
> Forwarding email to the mailing list...
>
> -- dims
>
> --- "Eadie, Alex" <Al...@team.telstra.com> wrote:
>
> > Hi Werner,
> >
> >
> >
> > We are trying use wss4j's UsernameToken functionality as a step up from
> > simple http authentication in our JBoss based application.
> >
> >
> >
> > The implementation in WSSecurityEngine.handleUsernameToken() that is
> > provided assumes that given a username from across the wire, the writer
> > of the UsernameTokenCallBack can return the bonafide password. However
> > in our case we cannot provide the bonafide password, we can only
> > ascertain whether a username/password combination is valid. This is
> > because the bonafide password is one-way hashed in our password
> > database.
> >
> >
> >
> > However the implementation of handleUsernameToken() also assumes that
> > the passwords sent across the wire are also one-way hashed. This
> > implies that it is not possible to get the password that came across the
> > wire back into clear text. Is this correct?
> >
> >
> >
> > If this is the case how did you see integration with an application
> > server working? When neither the password coming across the wire nor
> > the password available in the password database can be returned to clear
> > text and hence compared to each other.
> >
> >
> >
> > Is there any way the implementation can be modified to accommodate our
> > situation? This could be configurable using an additional parameter in
> > the deployment XML?
> >
> >
> >
> > Best Regards
> >
> > Alex Eadie
> >
> >
> >
> >
> >
> > Developer
> >
> > Telstra IADev
> >
> > Ph (02) 8255 3154
> >
> > Level 8
> >
> > 400 George St
> >
> > Sydney
> >
> >
> >
> >
>
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com