cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <dk...@apache.org>
Subject Re: Need clarification on the WS-SecurityPolicy documentation
Date Thu, 12 Nov 2009 15:03:30 GMT
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
dkulp@apache.org
http://www.dankulp.com/blog

Mime
View raw message