Hi Sam,

> -----Original Message-----
> From: Sam [mailto:[email protected]]
> Sent: Sonntag, 24. November 2013 00:39
> To: Andrei Shakirin
> Cc: [email protected]
> Subject: Re: Best practice of using external WS-Policy files with CXF?
> 
> Hi Andrei,
> 
> I think I will go for option C but the question is if a policy is targeted at
> wsdl:input, wsdl:output or sp:header, say signing then encrypt those parts,
> then how does policy reference parts of WSDL without using a) and b).

If you apply ws-policy using PolicyConstants.POLICY_OVERRIDE (option (c)), this 
effective policy is used to trigger interceptors for current message and all 
other ws-policies from service model are ignored (see PolicyInInterceptor and 
PolicyOutInterceptor for details).
Therefore, is up to you how to compose and merge effective policy - CXF doesn't 
care about any WSDL relations in this case, it will just use your effective 
policy.

> 
> Is there any sample code usage/examples of option C in CXF source code
> beside BindingPropertiesTest?

I will distil the option C in small sample and link it from my blog as soon as 
I find a bit a time to do that.

Regards,
Andrei.

> Thanks
> Sam
> 
> 
> On 21/11/2013 4:16 a.m., Andrei Shakirin wrote:
> > Hi,
> >
> > The policy what you found in
> rt/ws/security/src/test/resources/org/apache/cxf/ws/security/wss4j don't
> reference WSDL, but refer parts of SOAP message to be signed or encrypted.
> > That is not related to binding WS-Policy to WSDL.
> >
> > To bind the policies you have following options:
> > a) Embed WS-Policy into WSDL
> > b) use WS-PolicyAttachment
> > c) apply policy dynamically at runtime
> >
> > As Dennis said, you could refer to this CXF documents
> > http://cxf.apache.org/docs/ws-policy.html,
> > http://cxf.apache.org/docs/how-to-define-policies.html
> > and my blog:
> > http://ashakirin.blogspot.de/2012/02/using-ws-policy-in-cxf-projects.h
> > tml
> >
> > Regards,
> > Andrei.
> >
> >
> >> -----Original Message-----
> >> From: Sam [mailto:[email protected]]
> >> Sent: Dienstag, 19. November 2013 12:01
> >> To: [email protected]
> >> Subject: Best practice of using external WS-Policy files with CXF?
> >>
> >> Hi all,
> >>
> >> I found many sample policy files within /apache-cxf-2.7.6-
> >> src/rt/ws/security/src/test/resources/org/apache/cxf/ws/security/wss4
> >> j that don't use wsu:Id attribute at all in <wsp:Policy>, i.e.
> >> <wsp:Policy wsu:Id="test_policy">.
> >> This implies the WSDL doesn't even need to use <wsp:PolicyReference>
> >> to use them. Instead these policy files use something like the
> >> following to refer to parts of WSDL.
> >>
> >>         <sp:SignedParts>
> >>           <sp:Body/>
> >>           <sp:Header Name="Header" Namespace="http://www.sdj.pl"/>
> >>         </sp:SignedParts>
> >>         <sp:SignedParts>
> >>           <sp:Body/>
> >>           <sp:Header Namespace="http://www.sdj.pl"/>
> >>         </sp:SignedParts>
> >>
> >>           or use xpath like
> >>
> >>       <sp:EncryptedElements>
> >>           <sp:XPath>//soap:Body</sp:XPath>
> >>         </sp:EncryptedElements>
> >>
> >>          <sp:SignedElements>
> >>           <sp:XPath>//ser:Header</sp:XPath>
> >>         </sp:SignedElements>
> >>
> >> So just to confirm, is CXF capable of applying these reusable,
> >> external WS- Policy files to WSDL at runtime without modifying WSDL
> >> to use <wsp:PolicyReference>?
> >> What is the best practice of applying external WS-Policy files with CXF?
> >>
> >> I see no need to use <wsp:PolicyAttachment> at all if the above
> >> approach work for CXF. <wsp:PolicyAttachment> seems much less
> flexisble.
> >> All the CXF examples and forum discussions I read seem to suggest
> >> it's best to embed policy within WSDL but I can't see CONs of useing
> >> external WS- Policy files like above.
> >>
> >> What am I trying to do? I read the link
> >> http://ashakirin.blogspot.co.nz/2013/04/cxf-security-getting-certific
> >> ates-
> >> from.html
> >> and try to implement a WS client that can apply WS-Policy dynamically
> >> at run time  without touching WSDL.
> >>
> >> Thanks in advance,
> >>
> >> Sam

Reply via email to