Mailing-List: contact users-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cxf.apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Message-ID: <4FFD82CD.6000007@talend.com>
Date: Wed, 11 Jul 2012 09:42:37 -0400
From: Glen Mazza <gmazza@talend.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:13.0) Gecko/20120615 Thunderbird/13.0.1
MIME-Version: 1.0
To: <users@cxf.apache.org>
Subject: Re: Policy Alternatives not handled properly on client side
References: <1342010907503-5710882.post@n5.nabble.com>
In-Reply-To: <1342010907503-5710882.post@n5.nabble.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit

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