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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > >>>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/
