[
https://issues.apache.org/jira/browse/CXF-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792414#comment-16792414
]
Mike M. commented on CXF-7979:
------------------------------
[~coheigea]: (Sorry for pinging you, but this bug is really a blocker for
us...). Have you had the chance to look at the example project I created? It
should make the bug easy to reproduce. Let me know if there's anything I can do
to help.
> Issues when an operation's input and output should have different policies
> --------------------------------------------------------------------------
>
> Key: CXF-7979
> URL: https://issues.apache.org/jira/browse/CXF-7979
> Project: CXF
> Issue Type: Bug
> Components: JAX-WS Runtime
> Affects Versions: 3.3.0
> Environment: Tested with CXF 3.3.0, a reproducing example and unit
> test can be found here: https://github.com/netmikey/cxf-security-test
> Reporter: Mike M.
> Priority: Major
>
> We think we might have found an issue in the way WSDL-Embedded WebService
> Security Policies are interpreted at runtime.
> We are in contract-first mode, but don't use generated JAXB bindings. We use
> a {{@WebServiceProvider}} implementation as a dynamic server and use
> {{javax.xml.ws.Dispatch}} to build a dynamic client.
> The issue happens when we try to apply different WSS-Policies to an
> operation's {{wsdl:input}} and {{wsdl:output}}, so e.g. having the request
> secured but the response non-secured.
> We see different behavior depending on where we put the
> {{wsp:PolicyReference}} within the WSDL, but we didn't manage to make it
> work: either the client doesn't encrypt the request at all, or the server
> encrypts the response as well.
> I created a small but fully functional project on GitHub that contains a unit
> test which demonstrates the behavior (be sure to check the project's README).
> Please have a look at: https://github.com/netmikey/cxf-security-test
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
