On Thu November 12 2009 7:46:25 am Glen Mazza wrote: > Hello, a sentence in the CXF docs I believe I had placed in a while back I > would like to confirm--for the two code examples here: > > http://cwiki.apache.org/CXF20DOC/ws-securitypolicy.html#WS-SecurityPolicy-C > onfiguringviaSpring > > The sentence in question is: "The properties are easily configured as > client or endpoint properties--use the latter for web service provider > configuration:" > > Just to confirm: > > 1.) The *upper* code example is *only* for SOAP clients and not web service > providers
Right. > 2.) Is the *lower* code example *only* for web service providers, Yea. Only for the server side piece. > or can it > be equally used for both provider and client--also, if both, does the lower > example provide any advantage over the upper one when configuring a client? > > (I *might* have asked (1) and (2) before I placed that sentence in the > docs; if so, pardon my duplication!) > > 3.) The *lower* code example is currently somewhat nonsensical for web > service providers, because it has an "ws-security.username" entry--that > would normally only be for a client supplying a password, correct? Hmm.. Good point. Fixed! :-) > 4.) The "ws-security.callback-handler" entry seems to have two usages: For > the client-side, it is to supply the password but for the service-side, it > is to validate the supplied password, correct? If so, this would seem to > be confusing and suboptimal, if: > > --- 1.) A web service provider could need to supply both a password > (perhaps if forwarding to another web service call) *and* validate a > password--is that a realistic scenario not presently supported by our > configuration? Well, in that case, you would normally have two separate configurations: 1) A jaxws:endpoint which is the receiving side set to validate 2) A jaxws:client which is the sending side to where you are forwarding to. The two of them would have separate configs and with separate callback objects. > --- 2.) Architecturally, WSS4J may be moving away from using callback > handlers to validate passwords > (https://issues.apache.org/jira/browse/WSS-183) -- would it not be better > to have a separate property, say "ws-security.password-validator" or > ".authentication-validator" or whatever, strictly for validating passwords, > and letting "ws-security.callback-handler" just be for providing passwords > (or other authentication data)? Quite possible for 2.3 if we move to wss4j 1.6. (I'm hoping we can. Getting real Java5 collections in wss4j will be nice and remove a lot of crappy @SupressWarnings and unchecked casts and such.) Most likely, we'd check for ".authentication-validator" first and, if null, check for the old callback-handler for compatibility. -- Daniel Kulp dk...@apache.org http://www.dankulp.com/blog