For the interim, you can also use an CXF interceptor or JAX-WS handler
to remove the mustUnderstand attribute
(http://www.jroller.com/gmazza/entry/blog_article_index, links #43 and #44).
As I understand, the purpose of MustUnderstand is to ensure that the
headers are being sent exactly as they should be, preventing security
holes and making it easier to determine parameter misspellings as
opposed to inaccurate parameter values when errors occur. The remote
server shouldn't be choking on a mustUnderstand but recognizing that it
does indeed understand those parameters and continue handling the
call. It's probably a bad idea to deactivate the mustUnderstand by
default, defeating its usually beneficial purpose for all users, on the
basis of some remote servers not being programmed correctly to handle
it. That said, maybe UsernameTokenInterceptor can provide an option to
not set the MustUnderstand, while keeping the default value (if you
don't set this property) to the safe value of 1/true.
Glen
On 02/28/2012 05:40 PM, clickonchris wrote:
Hi folks,
I'm using CXF to implement a ws client. The wsdl I'm implementing against
has a UsernameToken security policy like this:
--------------
---------------------
In this case the default behavior for cxf seems to be to use the
UsernameTokenInterceptor.
I'm trying to minimize my xml configuration so I've attached the username
and password to the request like this:
Map<String, Object> ctx =
((BindingProvider)partnerProfileSvc).getRequestContext();
ctx.put("ws-security.username", "scott");
ctx.put("ws-security.password", "tiger");
My problem is that this ALWAYS sends a "mustUnderstand='1'" attribute in the
security header for my request, and the remote server chokes on it.
Furthermore, if I'm understanding this right, this seems to be HARD CODED
into the UsernameTokenInterceptor. Check it out:
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-ws-security/2.5.1/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java/#301
http://grepcode.com/file/repo1.maven.org/maven2/org.apache.cxf/cxf-rt-ws-security/2.5.1/org/apache/cxf/ws/security/wss4j/UsernameTokenInterceptor.java/#301
I tried using the WSS4JInterceptor, but it seems like once the
UsernameTokenInterceptor sets mustUnderstand, the WSS4JInterceptor cannot
unset it.
So my only solution in this case is to modify the wsdl to remove the
security policy, and just the WS4JInterceptor to manually insert the
UsernameToken security headers.
What I'm getting at, is that I think it is a big problem that
UsernameTokenInterceptor hard codes "mustUnderstand" to true. I feel like
opening a bug for it but I want to make sure that I'm using the framework
properly first, so please point out anywhere that I'm wrong in my logic.
Thanks!
--
View this message in context:
http://cxf.547215.n5.nabble.com/sending-mustUnderstand-0-with-UsernameTokenInterceptor-tp5523486p5523486.html
Sent from the cxf-user mailing list archive at Nabble.com.
--
Glen Mazza
Talend Community Coders - coders.talend.com
blog: www.jroller.com/gmazza
