I didn't read your message carefully. I didn't realize you were asking
this option for a different interceptor.
please ignore my message.
regards, aki

2012/2/29 Aki Yoshida <[email protected]>:
> You can either set the WSS4JOutInceteptor's property mustUnderstand to
> "false" or set this property to the message.
> In the latter case, you can use constant
> WSHandlerConstants.MUST_UNDERSTAND as the key.
>
> http://ws.apache.org/wss4j/apidocs/org/apache/ws/security/handler/WSHandlerConstants.html#MUST_UNDERSTAND
>
> I think this value is not read from the request context properties.
>
>
> 2012/2/28 clickonchris <[email protected]>:
>> 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.

Reply via email to