If you're not requiring a UsernameToken in one of the alternatives, that
would seem akin to never requiring a UsernameToken so I don't understand
the purpose of having an alternative requiring it.
If I understand your security situation correctly (I'm probably missing
something here), it's akin to saying "You don't have to supply me a
number, but if you decide to do so, it better be 693!!!" I'm not sure
what the difference security-wise between that and "You don't have to
supply me a number" would be, so why not just go with the latter?
Regards,
Glen
On 07/11/2012 08:48 AM, Yoann wrote:
I have a WSDL with the following policy:
<wsp:Policy wsu:Id="SecurityPolicy">
<wsp:ExactlyOne>
<wsp:All>
<wsp:PolicyReference
URI="#TransportSecurityBindingPolicy"/>
</wsp:All>
<wsp:All>
<wsp:PolicyReference
URI="#TransportSecurityBindingPolicy"/>
<wsp:PolicyReference
URI="#MessageSecurityBindingPolicy"/>
</wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
The MessageSecurityBindingPolicy mandates usage of a UsernameToken.
The policy is equivalent to:
<wsp:Policy wsu:Id="SecurityPolicy">
<wsp:PolicyReference URI="#TransportSecurityBindingPolicy" />
<wsp:PolicyReference URI="#MessageSecurityBindingPolicy"
wsp:Optional="true" />
</wsp:Policy>
The policy means the UsernameToken is optional.
My code relies on the support of WS-SecurityPolicy in CXF and is as follows:
mContext.put("ws-security.username", "USER");
mContext.put("ws-security.callback-handler", "test.ClientPasswordCallback");
The output message contains the WS-Security and verifies the second
alternative.
With the following:
mContext.remove("ws-security.username");
mContext.remove("ws-security.callback-handler");
The output message doesn't contain the WS-Security whereas it verifies the
first alternative.
Is there a way to force the alternative or could CXF check the username
properties are set (which is applicable as per policy definition) and set
the WS-Security according to the policy.
--
View this message in context:
http://cxf.547215.n5.nabble.com/Policy-Alternatives-not-handled-properly-on-client-side-tp5710882.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