Hi Andrei,
For option c, assuming the policy is reusable and specifies xml signing
then encrypt for soap request header and body. Then how does the policy
targets soap request header & body
without using a or b? That's the part I am confused about. For
usernameToken policy, there is no need to target wsdl parts, but for
signing/encrypt, policy does need to target wsdl parts.
Thanks
Sam
On 27/11/2013 1:15 a.m., Andrei Shakirin wrote:
Hi Sam,
-----Original Message-----
From: Sam [mailto:[email protected]]
Sent: Dienstag, 26. November 2013 10:20
To: Andrei Shakirin
Cc: [email protected]
Subject: Re: Best practice of using external WS-Policy files with CXF?
Hi Andrei,
This does mean the policy imported in option c could be using:
- option a: wsdl already contains <wsp:PolicyReference URI="#policyId"/> so
the policy applied at runtime will define actual <wsp:Policy
wsu:Id="policyId"> or
- option b: policyattachemnt element
and CXF should still work right?
Not sure that I got your question. If you use option (c), it doesn't matter how
your policy is related with WSDL.
You load file with ws-policy yourself, parse it with Neethi and apply to
POLICY_OVERRIDE message property. That's all.
All other policy related to WSDL will be ignored in this case. Take a look in
CXF PolicyInInterceptor and PolicyOutInterceptor code.
Regards,
Andrei.
Thanks
Sam
On 25/11/2013 6:20 a.m., Andrei Shakirin wrote:
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/ws
s4 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-certif
ic
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
