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 Andy Kriger <an...@gmail.com> on 2005/05/03 16:43:37 UTC
Re: UsernameToken authentication when a plain text password is us ed
This has been mentioned up by several people now. I have pointed out
previously that ignoring PasswordText creates a situation where
developers are using the WSS4J library for security but the security
can be bypassed if the client uses PasswordText. The developer is
expected to roll their own solution for an aspect of the security that
is in the specification but is not covererd by WSS4J (and it's not
obvious that one needs to do this since the behavior is undocumented).
I proposed a solution a while back that would maintain consistency
within WSS4J but never heard a response. From my previous email...
How about this:
* rename the property "passwordCallbackClass" to "digestCallbackClass"
* add support for a property "plaintextCallbackClass"
* this new class would also implement CallbackHandler
* in WSSecurityEngine.handleUsernameToken, an else block to the
if(ut.isHashed) could handoff password processing to the
plaintextCallbackClass (throwing an exception if it wasn't defined)
and if handle threw an Exception, WSSecurityEngine would exit with a
FAILED_AUTHENTICATION (that leaves all plaintext processing under the
full control of the user)
However, because I'm not thoroughly versed in the source code, I don't
know how that affects the creation/usage of WSUsernameTokenPrinicpal
from there.
It's not ideal because the user is required to throw an exception from
handle in order to trigger failure (as opposed to returning a value
that can be checked), but it is consistent with existing
functionality, doesn't require major changes (afaik), and doesn't let
plaintext passwords escape authentication.
On 5/3/05, Dittmann Werner <we...@siemens.com> wrote:
> Ruchith,
>
> WSS4J does not authticate if PasswordText is specified, it
> just returns the data to the application (Axis service).
> Also, in case of username token the password is optional.
>
> Indeed you are right about the specification of the password
> callback: we shall make it optional in case of PasswordText.
>
> Regards,
> Werner
>
> > -----Ursprüngliche Nachricht-----
> > Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> > Gesendet: Dienstag, 3. Mai 2005 11:26
> > An: WS-FX
> > Betreff: UsernameToken authentication when a plain text
> > password is used
> >
> >
> > Hi,
> >
> > I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
> > when passwordType="PasswordText".
> >
> > --------------------------------------------------------------
> > -------------------------------------------------------------
> > public WSUsernameTokenPrincipal handleUsernameToken(Element token,
> > CallbackHandler cb) throws WSSecurityException {
> > .....
> > .....
> > if (ut.isHashed()) {
> > //Authenticates the UT
> > }
> >
> > WSUsernameTokenPrincipal principal = new
> > WSUsernameTokenPrincipal(user, ut.isHashed());
> > principal.setNonce(nonce);
> > principal.setPassword(password);
> > principal.setCreatedTime(createdTime);
> >
> > return principal;
> > }
> >
> > --------------------------------------------------------------
> > -------------------------------------------------------------
> >
> > Is the above behaviour correct? If it is, in a situation where there's
> > only a UsernameToken (passwordType="PasswordText") is sent in the
> > security header, why should one specify the callback handler at the
> > service deployment?
> >
> > It's clear that the service impl can authenticate the UT as well,
> > using the WSSecurityEngineResult vector from the msgContext, but why
> > not authenticate at the Engine in the above instance?
> >
> > OR have I missed something obvious :-) ?
> >
> > Thanks in advance,
> > Ruchith Fernando
> >
>
Re: UsernameToken authentication when a plain text password is us ed
Posted by Davanum Srinivas <da...@gmail.com>.
Werner,
+1 from me. Now that Axis 1.2 has shipped, we need to put out a
release of WSS4J ASAP :)
-- dims
On 5/6/05, Werner Dittmann <We...@t-online.de> wrote:
> Andy, All,
>
> looking at the current implementation I would propose the following
> solution:
>
> - leave passwordCallbackClass property. Renaming it would break all existing
> deployments. passwordCallackClass is not only used for UsernameToken but
> for _every_ method that needs a password.
>
> - enhance the UsernameToken processing on the receiver side as follows:
> - add new data elements to the WSPasswordCallback data structure to hold
> the following new data elements: password, the string that
> identifies the
> password type
> - introduce a new WSPasswordCallback usage identifier
> USERNAME_TOKEN_UNKNOWN
>
> - the processing of a UsernameToken with a password type _not equal_ to
> "Digest"
> would be:
> - populate WSPasswordCallback with user, password, password type
> string, and
> usage identifier USERNAME_TOKEN_UNKNOWN
> - call the callback class (if one is specified, i.e. the reference to
> the callback class
> is not null)
>
> - because the callback class is "user implemented" all necessary checks
> (also application
> specific mechanisms can be applied here) can be performed.
>
> - if the callback fails, e.g. the password is wrong or because of some
> other problems
> it throws an excpetion - this way the security engine can throw its
> security exception
> as well.
>
> - if all is ok processing is as usual.
>
> As an additonal modification I would propose to add the password type
> string to the
> WSUsernameTokenPrincipal data structure to give an application all
> necessary information
> to deal with application specific userame/password setup (this could be
> done in addition
> to th above described handling)
>
> The above proposal would required a small modification of existing
> callback classes: insert
> the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as
> simple as
> just a return.
>
> Except from that the proposed modifications do not break existing
> deployments or interfaces
> because the are just additions.
>
> Any thoughts? I would like comments from those who are using
> UsernameToken or those
> who could be affected by the modifications.
>
> TIA.
>
> Regards,
> Werner
>
> Andy Kriger schrieb:
>
> >This has been mentioned up by several people now. I have pointed out
> >previously that ignoring PasswordText creates a situation where
> >developers are using the WSS4J library for security but the security
> >can be bypassed if the client uses PasswordText. The developer is
> >expected to roll their own solution for an aspect of the security that
> >is in the specification but is not covererd by WSS4J (and it's not
> >obvious that one needs to do this since the behavior is undocumented).
> >
> >I proposed a solution a while back that would maintain consistency
> >within WSS4J but never heard a response. From my previous email...
> >
> >How about this:
> >* rename the property "passwordCallbackClass" to "digestCallbackClass"
> >* add support for a property "plaintextCallbackClass"
> >* this new class would also implement CallbackHandler
> >* in WSSecurityEngine.handleUsernameToken, an else block to the
> >if(ut.isHashed) could handoff password processing to the
> >plaintextCallbackClass (throwing an exception if it wasn't defined)
> >and if handle threw an Exception, WSSecurityEngine would exit with a
> >FAILED_AUTHENTICATION (that leaves all plaintext processing under the
> >full control of the user)
> >
> >However, because I'm not thoroughly versed in the source code, I don't
> >know how that affects the creation/usage of WSUsernameTokenPrinicpal
> >from there.
> >
> >It's not ideal because the user is required to throw an exception from
> >handle in order to trigger failure (as opposed to returning a value
> >that can be checked), but it is consistent with existing
> >functionality, doesn't require major changes (afaik), and doesn't let
> >plaintext passwords escape authentication.
> >
> >On 5/3/05, Dittmann Werner <we...@siemens.com> wrote:
> >
> >
> >>Ruchith,
> >>
> >>WSS4J does not authticate if PasswordText is specified, it
> >>just returns the data to the application (Axis service).
> >>Also, in case of username token the password is optional.
> >>
> >>Indeed you are right about the specification of the password
> >>callback: we shall make it optional in case of PasswordText.
> >>
> >>Regards,
> >>Werner
> >>
> >>
> >>
> >>>-----Ursprüngliche Nachricht-----
> >>>Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
> >>>Gesendet: Dienstag, 3. Mai 2005 11:26
> >>>An: WS-FX
> >>>Betreff: UsernameToken authentication when a plain text
> >>>password is used
> >>>
> >>>
> >>>Hi,
> >>>
> >>>I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
> >>>when passwordType="PasswordText".
> >>>
> >>>--------------------------------------------------------------
> >>>-------------------------------------------------------------
> >>>public WSUsernameTokenPrincipal handleUsernameToken(Element token,
> >>>CallbackHandler cb) throws WSSecurityException {
> >>> .....
> >>> .....
> >>> if (ut.isHashed()) {
> >>> //Authenticates the UT
> >>> }
> >>>
> >>> WSUsernameTokenPrincipal principal = new
> >>>WSUsernameTokenPrincipal(user, ut.isHashed());
> >>> principal.setNonce(nonce);
> >>> principal.setPassword(password);
> >>> principal.setCreatedTime(createdTime);
> >>>
> >>> return principal;
> >>> }
> >>>
> >>>--------------------------------------------------------------
> >>>-------------------------------------------------------------
> >>>
> >>>Is the above behaviour correct? If it is, in a situation where there's
> >>>only a UsernameToken (passwordType="PasswordText") is sent in the
> >>>security header, why should one specify the callback handler at the
> >>>service deployment?
> >>>
> >>>It's clear that the service impl can authenticate the UT as well,
> >>>using the WSSecurityEngineResult vector from the msgContext, but why
> >>>not authenticate at the Engine in the above instance?
> >>>
> >>>OR have I missed something obvious :-) ?
> >>>
> >>>Thanks in advance,
> >>>Ruchith Fernando
> >>>
> >>>
> >>>
> >
> >
> >
>
>
--
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: UsernameToken authentication when a plain text password is us
ed
Posted by Matt Pavlovich <ma...@broadwing.com>.
I am new to WS SEC, and WSS4j, could someone please outline what the
PasswordText security hole is?
Andy Kriger wrote:
>+1 - solution stays within the WSS4J framework and doesn't leave the
>PasswordText security hole
>
>I'd add that the tutorial docs should reflect this info so that
>developers know they need to address both PasswordText and
>PasswordDigest in the callback class.
>
>Thank you for taking the time to address this issue
>
>-a
>
>On 5/6/05, Werner Dittmann <We...@t-online.de> wrote:
>
>
>>Andy, All,
>>
>>looking at the current implementation I would propose the following
>>solution:
>>
>>- leave passwordCallbackClass property. Renaming it would break all existing
>> deployments. passwordCallackClass is not only used for UsernameToken but
>> for _every_ method that needs a password.
>>
>>- enhance the UsernameToken processing on the receiver side as follows:
>> - add new data elements to the WSPasswordCallback data structure to hold
>> the following new data elements: password, the string that
>>identifies the
>> password type
>> - introduce a new WSPasswordCallback usage identifier
>>USERNAME_TOKEN_UNKNOWN
>>
>>- the processing of a UsernameToken with a password type _not equal_ to
>>"Digest"
>> would be:
>> - populate WSPasswordCallback with user, password, password type
>>string, and
>> usage identifier USERNAME_TOKEN_UNKNOWN
>> - call the callback class (if one is specified, i.e. the reference to
>>the callback class
>> is not null)
>>
>>- because the callback class is "user implemented" all necessary checks
>>(also application
>> specific mechanisms can be applied here) can be performed.
>>
>>- if the callback fails, e.g. the password is wrong or because of some
>>other problems
>> it throws an excpetion - this way the security engine can throw its
>>security exception
>> as well.
>>
>>- if all is ok processing is as usual.
>>
>>As an additonal modification I would propose to add the password type
>>string to the
>>WSUsernameTokenPrincipal data structure to give an application all
>>necessary information
>>to deal with application specific userame/password setup (this could be
>>done in addition
>>to th above described handling)
>>
>>The above proposal would required a small modification of existing
>>callback classes: insert
>>the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as
>>simple as
>>just a return.
>>
>>Except from that the proposed modifications do not break existing
>>deployments or interfaces
>>because the are just additions.
>>
>>Any thoughts? I would like comments from those who are using
>>UsernameToken or those
>>who could be affected by the modifications.
>>
>>TIA.
>>
>>Regards,
>>Werner
>>
>>Andy Kriger schrieb:
>>
>>
>>
>>>This has been mentioned up by several people now. I have pointed out
>>>previously that ignoring PasswordText creates a situation where
>>>developers are using the WSS4J library for security but the security
>>>can be bypassed if the client uses PasswordText. The developer is
>>>expected to roll their own solution for an aspect of the security that
>>>is in the specification but is not covererd by WSS4J (and it's not
>>>obvious that one needs to do this since the behavior is undocumented).
>>>
>>>I proposed a solution a while back that would maintain consistency
>>>within WSS4J but never heard a response. From my previous email...
>>>
>>>How about this:
>>>* rename the property "passwordCallbackClass" to "digestCallbackClass"
>>>* add support for a property "plaintextCallbackClass"
>>>* this new class would also implement CallbackHandler
>>>* in WSSecurityEngine.handleUsernameToken, an else block to the
>>>if(ut.isHashed) could handoff password processing to the
>>>plaintextCallbackClass (throwing an exception if it wasn't defined)
>>>and if handle threw an Exception, WSSecurityEngine would exit with a
>>>FAILED_AUTHENTICATION (that leaves all plaintext processing under the
>>>full control of the user)
>>>
>>>However, because I'm not thoroughly versed in the source code, I don't
>>>know how that affects the creation/usage of WSUsernameTokenPrinicpal
>>>
>>>
>>>from there.
>>
>>
>>>It's not ideal because the user is required to throw an exception from
>>>handle in order to trigger failure (as opposed to returning a value
>>>that can be checked), but it is consistent with existing
>>>functionality, doesn't require major changes (afaik), and doesn't let
>>>plaintext passwords escape authentication.
>>>
>>>On 5/3/05, Dittmann Werner <werner.dittmann@siemens.com > wrote:
>>>
>>>
>>>
>>>
>>>>Ruchith,
>>>>
>>>>WSS4J does not authticate if PasswordText is specified, it
>>>>just returns the data to the application (Axis service).
>>>>Also, in case of username token the password is optional.
>>>>
>>>>Indeed you are right about the specification of the password
>>>>callback: we shall make it optional in case of PasswordText.
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Ursprüngliche Nachricht-----
>>>>>Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com ]
>>>>>Gesendet: Dienstag, 3. Mai 2005 11:26
>>>>>An: WS-FX
>>>>>Betreff: UsernameToken authentication when a plain text
>>>>>password is used
>>>>>
>>>>>
>>>>>Hi,
>>>>>
>>>>>I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
>>>>>when passwordType="PasswordText".
>>>>>
>>>>>--------------------------------------------------------------
>>>>>-------------------------------------------------------------
>>>>>public WSUsernameTokenPrincipal handleUsernameToken(Element token,
>>>>>CallbackHandler cb) throws WSSecurityException {
>>>>> .....
>>>>> .....
>>>>> if (ut.isHashed()) {
>>>>> //Authenticates the UT
>>>>> }
>>>>>
>>>>> WSUsernameTokenPrincipal principal = new
>>>>>WSUsernameTokenPrincipal(user, ut.isHashed());
>>>>> principal.setNonce(nonce);
>>>>> principal.setPassword(password);
>>>>> principal.setCreatedTime(createdTime);
>>>>>
>>>>> return principal;
>>>>> }
>>>>>
>>>>>--------------------------------------------------------------
>>>>>-------------------------------------------------------------
>>>>>
>>>>>Is the above behaviour correct? If it is, in a situation where there's
>>>>>only a UsernameToken (passwordType="PasswordText") is sent in the
>>>>>security header, why should one specify the callback handler at the
>>>>>service deployment?
>>>>>
>>>>>It's clear that the service impl can authenticate the UT as well,
>>>>>using the WSSecurityEngineResult vector from the msgContext, but why
>>>>>not authenticate at the Engine in the above instance?
>>>>>
>>>>>OR have I missed something obvious :-) ?
>>>>>
>>>>>Thanks in advance,
>>>>>Ruchith Fernando
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
Re: UsernameToken authentication when a plain text password is us ed
Posted by Andy Kriger <an...@gmail.com>.
I finally had a chance to verify that this works. Added code to my
callback class to handle the password verification and all is well.
Thank you for working out something that kept all the authentication
in one place.
On 5/6/05, Werner Dittmann <We...@t-online.de> wrote:
> Andy, all
>
> just checkd in the modifications. Pls have a look. Depending on the
> implementation of the callback class it may be necessary to modify
> it as describe below. Very simple callback classes would run without
> mods. However, I modified the callback class used in the interop test
> to give a small hint how to do it.
>
> As for the tutorial - this needs an overhaul anyhow. Maybe I can address
> this during the weekend - if the weather remains as ugly as it is today :-)
>
> Regards,
> Werner
>
> Andy Kriger schrieb:
>
> >+1 - solution stays within the WSS4J framework and doesn't leave the
> >PasswordText security hole
> >
> >I'd add that the tutorial docs should reflect this info so that
> >developers know they need to address both PasswordText and
> >PasswordDigest in the callback class.
> >
> >Thank you for taking the time to address this issue
> >
> >-a
> >
> >On 5/6/05, Werner Dittmann <We...@t-online.de> wrote:
> >
> >
> >>Andy, All,
> >>
> >>looking at the current implementation I would propose the following
> >>solution:
> >>
> >>- leave passwordCallbackClass property. Renaming it would break all existing
> >> deployments. passwordCallackClass is not only used for UsernameToken but
> >> for _every_ method that needs a password.
> >>
> >>- enhance the UsernameToken processing on the receiver side as follows:
> >> - add new data elements to the WSPasswordCallback data structure to hold
> >> the following new data elements: password, the string that
> >>identifies the
> >> password type
> >> - introduce a new WSPasswordCallback usage identifier
> >>USERNAME_TOKEN_UNKNOWN
> >>
> >>- the processing of a UsernameToken with a password type _not equal_ to
> >>"Digest"
> >> would be:
> >> - populate WSPasswordCallback with user, password, password type
> >>string, and
> >> usage identifier USERNAME_TOKEN_UNKNOWN
> >> - call the callback class (if one is specified, i.e. the reference to
> >>the callback class
> >> is not null)
> >>
> >>- because the callback class is "user implemented" all necessary checks
> >>(also application
> >> specific mechanisms can be applied here) can be performed.
> >>
> >>- if the callback fails, e.g. the password is wrong or because of some
> >>other problems
> >> it throws an excpetion - this way the security engine can throw its
> >>security exception
> >> as well.
> >>
> >>- if all is ok processing is as usual.
> >>
> >>As an additonal modification I would propose to add the password type
> >>string to the
> >>WSUsernameTokenPrincipal data structure to give an application all
> >>necessary information
> >>to deal with application specific userame/password setup (this could be
> >>done in addition
> >>to th above described handling)
> >>
> >>The above proposal would required a small modification of existing
> >>callback classes: insert
> >>the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as
> >>simple as
> >>just a return.
> >>
> >>Except from that the proposed modifications do not break existing
> >>deployments or interfaces
> >>because the are just additions.
> >>
> >>Any thoughts? I would like comments from those who are using
> >>UsernameToken or those
> >>who could be affected by the modifications.
> >>
> >>TIA.
> >>
> >>Regards,
> >>Werner
> >>
> >>Andy Kriger schrieb:
> >>
> >>
> >>
> >>>This has been mentioned up by several people now. I have pointed out
> >>>previously that ignoring PasswordText creates a situation where
> >>>developers are using the WSS4J library for security but the security
> >>>can be bypassed if the client uses PasswordText. The developer is
> >>>expected to roll their own solution for an aspect of the security that
> >>>is in the specification but is not covererd by WSS4J (and it's not
> >>>obvious that one needs to do this since the behavior is undocumented).
> >>>
> >>>I proposed a solution a while back that would maintain consistency
> >>>within WSS4J but never heard a response. From my previous email...
> >>>
> >>>How about this:
> >>>* rename the property "passwordCallbackClass" to "digestCallbackClass"
> >>>* add support for a property "plaintextCallbackClass"
> >>>* this new class would also implement CallbackHandler
> >>>* in WSSecurityEngine.handleUsernameToken, an else block to the
> >>>if(ut.isHashed) could handoff password processing to the
> >>>plaintextCallbackClass (throwing an exception if it wasn't defined)
> >>>and if handle threw an Exception, WSSecurityEngine would exit with a
> >>>FAILED_AUTHENTICATION (that leaves all plaintext processing under the
> >>>full control of the user)
> >>>
> >>>However, because I'm not thoroughly versed in the source code, I don't
> >>>know how that affects the creation/usage of WSUsernameTokenPrinicpal
> >>>
> >>>
> >>>from there.
> >>
> >>
> >>>It's not ideal because the user is required to throw an exception from
> >>>handle in order to trigger failure (as opposed to returning a value
> >>>that can be checked), but it is consistent with existing
> >>>functionality, doesn't require major changes (afaik), and doesn't let
> >>>plaintext passwords escape authentication.
> >>>
> >>>On 5/3/05, Dittmann Werner <werner.dittmann@siemens.com > wrote:
> >>>
> >>>
> >>>
> >>>
> >>>>Ruchith,
> >>>>
> >>>>WSS4J does not authticate if PasswordText is specified, it
> >>>>just returns the data to the application (Axis service).
> >>>>Also, in case of username token the password is optional.
> >>>>
> >>>>Indeed you are right about the specification of the password
> >>>>callback: we shall make it optional in case of PasswordText.
> >>>>
> >>>>Regards,
> >>>>Werner
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>>-----Ursprüngliche Nachricht-----
> >>>>>Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com ]
> >>>>>Gesendet: Dienstag, 3. Mai 2005 11:26
> >>>>>An: WS-FX
> >>>>>Betreff: UsernameToken authentication when a plain text
> >>>>>password is used
> >>>>>
> >>>>>
> >>>>>Hi,
> >>>>>
> >>>>>I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
> >>>>>when passwordType="PasswordText".
> >>>>>
> >>>>>--------------------------------------------------------------
> >>>>>-------------------------------------------------------------
> >>>>>public WSUsernameTokenPrincipal handleUsernameToken(Element token,
> >>>>>CallbackHandler cb) throws WSSecurityException {
> >>>>> .....
> >>>>> .....
> >>>>> if (ut.isHashed()) {
> >>>>> //Authenticates the UT
> >>>>> }
> >>>>>
> >>>>> WSUsernameTokenPrincipal principal = new
> >>>>>WSUsernameTokenPrincipal(user, ut.isHashed());
> >>>>> principal.setNonce(nonce);
> >>>>> principal.setPassword(password);
> >>>>> principal.setCreatedTime(createdTime);
> >>>>>
> >>>>> return principal;
> >>>>> }
> >>>>>
> >>>>>--------------------------------------------------------------
> >>>>>-------------------------------------------------------------
> >>>>>
> >>>>>Is the above behaviour correct? If it is, in a situation where there's
> >>>>>only a UsernameToken (passwordType="PasswordText") is sent in the
> >>>>>security header, why should one specify the callback handler at the
> >>>>>service deployment?
> >>>>>
> >>>>>It's clear that the service impl can authenticate the UT as well,
> >>>>>using the WSSecurityEngineResult vector from the msgContext, but why
> >>>>>not authenticate at the Engine in the above instance?
> >>>>>
> >>>>>OR have I missed something obvious :-) ?
> >>>>>
> >>>>>Thanks in advance,
> >>>>>Ruchith Fernando
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>>>
> >>>
> >>>
> >>>
> >>
> >>
> >
> >
> >
>
>
Re: UsernameToken authentication when a plain text password is us
ed
Posted by Werner Dittmann <We...@t-online.de>.
Andy, all
just checkd in the modifications. Pls have a look. Depending on the
implementation of the callback class it may be necessary to modify
it as describe below. Very simple callback classes would run without
mods. However, I modified the callback class used in the interop test
to give a small hint how to do it.
As for the tutorial - this needs an overhaul anyhow. Maybe I can address
this during the weekend - if the weather remains as ugly as it is today :-)
Regards,
Werner
Andy Kriger schrieb:
>+1 - solution stays within the WSS4J framework and doesn't leave the
>PasswordText security hole
>
>I'd add that the tutorial docs should reflect this info so that
>developers know they need to address both PasswordText and
>PasswordDigest in the callback class.
>
>Thank you for taking the time to address this issue
>
>-a
>
>On 5/6/05, Werner Dittmann <We...@t-online.de> wrote:
>
>
>>Andy, All,
>>
>>looking at the current implementation I would propose the following
>>solution:
>>
>>- leave passwordCallbackClass property. Renaming it would break all existing
>> deployments. passwordCallackClass is not only used for UsernameToken but
>> for _every_ method that needs a password.
>>
>>- enhance the UsernameToken processing on the receiver side as follows:
>> - add new data elements to the WSPasswordCallback data structure to hold
>> the following new data elements: password, the string that
>>identifies the
>> password type
>> - introduce a new WSPasswordCallback usage identifier
>>USERNAME_TOKEN_UNKNOWN
>>
>>- the processing of a UsernameToken with a password type _not equal_ to
>>"Digest"
>> would be:
>> - populate WSPasswordCallback with user, password, password type
>>string, and
>> usage identifier USERNAME_TOKEN_UNKNOWN
>> - call the callback class (if one is specified, i.e. the reference to
>>the callback class
>> is not null)
>>
>>- because the callback class is "user implemented" all necessary checks
>>(also application
>> specific mechanisms can be applied here) can be performed.
>>
>>- if the callback fails, e.g. the password is wrong or because of some
>>other problems
>> it throws an excpetion - this way the security engine can throw its
>>security exception
>> as well.
>>
>>- if all is ok processing is as usual.
>>
>>As an additonal modification I would propose to add the password type
>>string to the
>>WSUsernameTokenPrincipal data structure to give an application all
>>necessary information
>>to deal with application specific userame/password setup (this could be
>>done in addition
>>to th above described handling)
>>
>>The above proposal would required a small modification of existing
>>callback classes: insert
>>the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as
>>simple as
>>just a return.
>>
>>Except from that the proposed modifications do not break existing
>>deployments or interfaces
>>because the are just additions.
>>
>>Any thoughts? I would like comments from those who are using
>>UsernameToken or those
>>who could be affected by the modifications.
>>
>>TIA.
>>
>>Regards,
>>Werner
>>
>>Andy Kriger schrieb:
>>
>>
>>
>>>This has been mentioned up by several people now. I have pointed out
>>>previously that ignoring PasswordText creates a situation where
>>>developers are using the WSS4J library for security but the security
>>>can be bypassed if the client uses PasswordText. The developer is
>>>expected to roll their own solution for an aspect of the security that
>>>is in the specification but is not covererd by WSS4J (and it's not
>>>obvious that one needs to do this since the behavior is undocumented).
>>>
>>>I proposed a solution a while back that would maintain consistency
>>>within WSS4J but never heard a response. From my previous email...
>>>
>>>How about this:
>>>* rename the property "passwordCallbackClass" to "digestCallbackClass"
>>>* add support for a property "plaintextCallbackClass"
>>>* this new class would also implement CallbackHandler
>>>* in WSSecurityEngine.handleUsernameToken, an else block to the
>>>if(ut.isHashed) could handoff password processing to the
>>>plaintextCallbackClass (throwing an exception if it wasn't defined)
>>>and if handle threw an Exception, WSSecurityEngine would exit with a
>>>FAILED_AUTHENTICATION (that leaves all plaintext processing under the
>>>full control of the user)
>>>
>>>However, because I'm not thoroughly versed in the source code, I don't
>>>know how that affects the creation/usage of WSUsernameTokenPrinicpal
>>>
>>>
>>>from there.
>>
>>
>>>It's not ideal because the user is required to throw an exception from
>>>handle in order to trigger failure (as opposed to returning a value
>>>that can be checked), but it is consistent with existing
>>>functionality, doesn't require major changes (afaik), and doesn't let
>>>plaintext passwords escape authentication.
>>>
>>>On 5/3/05, Dittmann Werner <werner.dittmann@siemens.com > wrote:
>>>
>>>
>>>
>>>
>>>>Ruchith,
>>>>
>>>>WSS4J does not authticate if PasswordText is specified, it
>>>>just returns the data to the application (Axis service).
>>>>Also, in case of username token the password is optional.
>>>>
>>>>Indeed you are right about the specification of the password
>>>>callback: we shall make it optional in case of PasswordText.
>>>>
>>>>Regards,
>>>>Werner
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>>-----Ursprüngliche Nachricht-----
>>>>>Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com ]
>>>>>Gesendet: Dienstag, 3. Mai 2005 11:26
>>>>>An: WS-FX
>>>>>Betreff: UsernameToken authentication when a plain text
>>>>>password is used
>>>>>
>>>>>
>>>>>Hi,
>>>>>
>>>>>I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
>>>>>when passwordType="PasswordText".
>>>>>
>>>>>--------------------------------------------------------------
>>>>>-------------------------------------------------------------
>>>>>public WSUsernameTokenPrincipal handleUsernameToken(Element token,
>>>>>CallbackHandler cb) throws WSSecurityException {
>>>>> .....
>>>>> .....
>>>>> if (ut.isHashed()) {
>>>>> //Authenticates the UT
>>>>> }
>>>>>
>>>>> WSUsernameTokenPrincipal principal = new
>>>>>WSUsernameTokenPrincipal(user, ut.isHashed());
>>>>> principal.setNonce(nonce);
>>>>> principal.setPassword(password);
>>>>> principal.setCreatedTime(createdTime);
>>>>>
>>>>> return principal;
>>>>> }
>>>>>
>>>>>--------------------------------------------------------------
>>>>>-------------------------------------------------------------
>>>>>
>>>>>Is the above behaviour correct? If it is, in a situation where there's
>>>>>only a UsernameToken (passwordType="PasswordText") is sent in the
>>>>>security header, why should one specify the callback handler at the
>>>>>service deployment?
>>>>>
>>>>>It's clear that the service impl can authenticate the UT as well,
>>>>>using the WSSecurityEngineResult vector from the msgContext, but why
>>>>>not authenticate at the Engine in the above instance?
>>>>>
>>>>>OR have I missed something obvious :-) ?
>>>>>
>>>>>Thanks in advance,
>>>>>Ruchith Fernando
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
>
>
>
Re: UsernameToken authentication when a plain text password is us ed
Posted by Andy Kriger <an...@gmail.com>.
+1 - solution stays within the WSS4J framework and doesn't leave the
PasswordText security hole
I'd add that the tutorial docs should reflect this info so that
developers know they need to address both PasswordText and
PasswordDigest in the callback class.
Thank you for taking the time to address this issue
-a
On 5/6/05, Werner Dittmann <We...@t-online.de> wrote:
> Andy, All,
>
> looking at the current implementation I would propose the following
> solution:
>
> - leave passwordCallbackClass property. Renaming it would break all existing
> deployments. passwordCallackClass is not only used for UsernameToken but
> for _every_ method that needs a password.
>
> - enhance the UsernameToken processing on the receiver side as follows:
> - add new data elements to the WSPasswordCallback data structure to hold
> the following new data elements: password, the string that
> identifies the
> password type
> - introduce a new WSPasswordCallback usage identifier
> USERNAME_TOKEN_UNKNOWN
>
> - the processing of a UsernameToken with a password type _not equal_ to
> "Digest"
> would be:
> - populate WSPasswordCallback with user, password, password type
> string, and
> usage identifier USERNAME_TOKEN_UNKNOWN
> - call the callback class (if one is specified, i.e. the reference to
> the callback class
> is not null)
>
> - because the callback class is "user implemented" all necessary checks
> (also application
> specific mechanisms can be applied here) can be performed.
>
> - if the callback fails, e.g. the password is wrong or because of some
> other problems
> it throws an excpetion - this way the security engine can throw its
> security exception
> as well.
>
> - if all is ok processing is as usual.
>
> As an additonal modification I would propose to add the password type
> string to the
> WSUsernameTokenPrincipal data structure to give an application all
> necessary information
> to deal with application specific userame/password setup (this could be
> done in addition
> to th above described handling)
>
> The above proposal would required a small modification of existing
> callback classes: insert
> the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as
> simple as
> just a return.
>
> Except from that the proposed modifications do not break existing
> deployments or interfaces
> because the are just additions.
>
> Any thoughts? I would like comments from those who are using
> UsernameToken or those
> who could be affected by the modifications.
>
> TIA.
>
> Regards,
> Werner
>
> Andy Kriger schrieb:
>
> >This has been mentioned up by several people now. I have pointed out
> >previously that ignoring PasswordText creates a situation where
> >developers are using the WSS4J library for security but the security
> >can be bypassed if the client uses PasswordText. The developer is
> >expected to roll their own solution for an aspect of the security that
> >is in the specification but is not covererd by WSS4J (and it's not
> >obvious that one needs to do this since the behavior is undocumented).
> >
> >I proposed a solution a while back that would maintain consistency
> >within WSS4J but never heard a response. From my previous email...
> >
> >How about this:
> >* rename the property "passwordCallbackClass" to "digestCallbackClass"
> >* add support for a property "plaintextCallbackClass"
> >* this new class would also implement CallbackHandler
> >* in WSSecurityEngine.handleUsernameToken, an else block to the
> >if(ut.isHashed) could handoff password processing to the
> >plaintextCallbackClass (throwing an exception if it wasn't defined)
> >and if handle threw an Exception, WSSecurityEngine would exit with a
> >FAILED_AUTHENTICATION (that leaves all plaintext processing under the
> >full control of the user)
> >
> >However, because I'm not thoroughly versed in the source code, I don't
> >know how that affects the creation/usage of WSUsernameTokenPrinicpal
> >from there.
> >
> >It's not ideal because the user is required to throw an exception from
> >handle in order to trigger failure (as opposed to returning a value
> >that can be checked), but it is consistent with existing
> >functionality, doesn't require major changes (afaik), and doesn't let
> >plaintext passwords escape authentication.
> >
> >On 5/3/05, Dittmann Werner <werner.dittmann@siemens.com > wrote:
> >
> >
> >>Ruchith,
> >>
> >>WSS4J does not authticate if PasswordText is specified, it
> >>just returns the data to the application (Axis service).
> >>Also, in case of username token the password is optional.
> >>
> >>Indeed you are right about the specification of the password
> >>callback: we shall make it optional in case of PasswordText.
> >>
> >>Regards,
> >>Werner
> >>
> >>
> >>
> >>>-----Ursprüngliche Nachricht-----
> >>>Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com ]
> >>>Gesendet: Dienstag, 3. Mai 2005 11:26
> >>>An: WS-FX
> >>>Betreff: UsernameToken authentication when a plain text
> >>>password is used
> >>>
> >>>
> >>>Hi,
> >>>
> >>>I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
> >>>when passwordType="PasswordText".
> >>>
> >>>--------------------------------------------------------------
> >>>-------------------------------------------------------------
> >>>public WSUsernameTokenPrincipal handleUsernameToken(Element token,
> >>>CallbackHandler cb) throws WSSecurityException {
> >>> .....
> >>> .....
> >>> if (ut.isHashed()) {
> >>> //Authenticates the UT
> >>> }
> >>>
> >>> WSUsernameTokenPrincipal principal = new
> >>>WSUsernameTokenPrincipal(user, ut.isHashed());
> >>> principal.setNonce(nonce);
> >>> principal.setPassword(password);
> >>> principal.setCreatedTime(createdTime);
> >>>
> >>> return principal;
> >>> }
> >>>
> >>>--------------------------------------------------------------
> >>>-------------------------------------------------------------
> >>>
> >>>Is the above behaviour correct? If it is, in a situation where there's
> >>>only a UsernameToken (passwordType="PasswordText") is sent in the
> >>>security header, why should one specify the callback handler at the
> >>>service deployment?
> >>>
> >>>It's clear that the service impl can authenticate the UT as well,
> >>>using the WSSecurityEngineResult vector from the msgContext, but why
> >>>not authenticate at the Engine in the above instance?
> >>>
> >>>OR have I missed something obvious :-) ?
> >>>
> >>>Thanks in advance,
> >>>Ruchith Fernando
> >>>
> >>>
> >>>
> >
> >
> >
>
>
Re: UsernameToken authentication when a plain text password is us
ed
Posted by Werner Dittmann <We...@t-online.de>.
Andy, All,
looking at the current implementation I would propose the following
solution:
- leave passwordCallbackClass property. Renaming it would break all existing
deployments. passwordCallackClass is not only used for UsernameToken but
for _every_ method that needs a password.
- enhance the UsernameToken processing on the receiver side as follows:
- add new data elements to the WSPasswordCallback data structure to hold
the following new data elements: password, the string that
identifies the
password type
- introduce a new WSPasswordCallback usage identifier
USERNAME_TOKEN_UNKNOWN
- the processing of a UsernameToken with a password type _not equal_ to
"Digest"
would be:
- populate WSPasswordCallback with user, password, password type
string, and
usage identifier USERNAME_TOKEN_UNKNOWN
- call the callback class (if one is specified, i.e. the reference to
the callback class
is not null)
- because the callback class is "user implemented" all necessary checks
(also application
specific mechanisms can be applied here) can be performed.
- if the callback fails, e.g. the password is wrong or because of some
other problems
it throws an excpetion - this way the security engine can throw its
security exception
as well.
- if all is ok processing is as usual.
As an additonal modification I would propose to add the password type
string to the
WSUsernameTokenPrincipal data structure to give an application all
necessary information
to deal with application specific userame/password setup (this could be
done in addition
to th above described handling)
The above proposal would required a small modification of existing
callback classes: insert
the handling of callback usage USERNAME_TOKEN_UNKNOWN - could be as
simple as
just a return.
Except from that the proposed modifications do not break existing
deployments or interfaces
because the are just additions.
Any thoughts? I would like comments from those who are using
UsernameToken or those
who could be affected by the modifications.
TIA.
Regards,
Werner
Andy Kriger schrieb:
>This has been mentioned up by several people now. I have pointed out
>previously that ignoring PasswordText creates a situation where
>developers are using the WSS4J library for security but the security
>can be bypassed if the client uses PasswordText. The developer is
>expected to roll their own solution for an aspect of the security that
>is in the specification but is not covererd by WSS4J (and it's not
>obvious that one needs to do this since the behavior is undocumented).
>
>I proposed a solution a while back that would maintain consistency
>within WSS4J but never heard a response. From my previous email...
>
>How about this:
>* rename the property "passwordCallbackClass" to "digestCallbackClass"
>* add support for a property "plaintextCallbackClass"
>* this new class would also implement CallbackHandler
>* in WSSecurityEngine.handleUsernameToken, an else block to the
>if(ut.isHashed) could handoff password processing to the
>plaintextCallbackClass (throwing an exception if it wasn't defined)
>and if handle threw an Exception, WSSecurityEngine would exit with a
>FAILED_AUTHENTICATION (that leaves all plaintext processing under the
>full control of the user)
>
>However, because I'm not thoroughly versed in the source code, I don't
>know how that affects the creation/usage of WSUsernameTokenPrinicpal
>from there.
>
>It's not ideal because the user is required to throw an exception from
>handle in order to trigger failure (as opposed to returning a value
>that can be checked), but it is consistent with existing
>functionality, doesn't require major changes (afaik), and doesn't let
>plaintext passwords escape authentication.
>
>On 5/3/05, Dittmann Werner <we...@siemens.com> wrote:
>
>
>>Ruchith,
>>
>>WSS4J does not authticate if PasswordText is specified, it
>>just returns the data to the application (Axis service).
>>Also, in case of username token the password is optional.
>>
>>Indeed you are right about the specification of the password
>>callback: we shall make it optional in case of PasswordText.
>>
>>Regards,
>>Werner
>>
>>
>>
>>>-----Ursprüngliche Nachricht-----
>>>Von: Ruchith Fernando [mailto:ruchith.fernando@gmail.com]
>>>Gesendet: Dienstag, 3. Mai 2005 11:26
>>>An: WS-FX
>>>Betreff: UsernameToken authentication when a plain text
>>>password is used
>>>
>>>
>>>Hi,
>>>
>>>I noticed that WSSecurityEngine doesn't authenticate the UsernameToken
>>>when passwordType="PasswordText".
>>>
>>>--------------------------------------------------------------
>>>-------------------------------------------------------------
>>>public WSUsernameTokenPrincipal handleUsernameToken(Element token,
>>>CallbackHandler cb) throws WSSecurityException {
>>> .....
>>> .....
>>> if (ut.isHashed()) {
>>> //Authenticates the UT
>>> }
>>>
>>> WSUsernameTokenPrincipal principal = new
>>>WSUsernameTokenPrincipal(user, ut.isHashed());
>>> principal.setNonce(nonce);
>>> principal.setPassword(password);
>>> principal.setCreatedTime(createdTime);
>>>
>>> return principal;
>>> }
>>>
>>>--------------------------------------------------------------
>>>-------------------------------------------------------------
>>>
>>>Is the above behaviour correct? If it is, in a situation where there's
>>>only a UsernameToken (passwordType="PasswordText") is sent in the
>>>security header, why should one specify the callback handler at the
>>>service deployment?
>>>
>>>It's clear that the service impl can authenticate the UT as well,
>>>using the WSSecurityEngineResult vector from the msgContext, but why
>>>not authenticate at the Engine in the above instance?
>>>
>>>OR have I missed something obvious :-) ?
>>>
>>>Thanks in advance,
>>>Ruchith Fernando
>>>
>>>
>>>
>
>
>