[
https://issues.apache.org/jira/browse/CXF-7979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16800546#comment-16800546
]
Mike M. commented on CXF-7979:
------------------------------
Hi [~coheigea],
First of all, thanks a lot for looking into this and for your explanation and
workaround, which works of course. You honestly helped us out a lot!
If you allow, I'd like to follow up this ticket. Maybe some improvement could
be considered, be it only to keep others from stumbling into the same pitfall.
# Is there any place (the docs maybe?) where I should have looked that could
have told me what I was doing wrong or how I was supposed to do it correctly?
# It might be an improvement if CXF informed the developer that it was missing
some information to do its job correctly, maybe through a log message. That
would have pointed us in the right direction in this particular case.
# After thinking about it a bit: Why does CXF require the developer to tell it
the operation in the first place? I mean, technically, in this concrete
situation CXF already knew the WSDL and the XML Element used as Document for
the SOAPMessage to be sent. Couldn't it have looked up the matching operation
in the WSDL? If it wouldn't find one, it could still inform that there was
something weird going on (see 2.).
Also, thank you for clarifying that an empty policy cannot "override" a secure
policy declared on a higher hierarchical level within a WSDL like we did. Is
there, to your knowledge, any other way of doing so? The goal being a
declaration like "apply this security for everything within this WSDL by
default, except for those few cases excluded explicitly".
Thanks again for your support.
Best regards,
Mike
> 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.
> Assignee: Colm O hEigeartaigh
> 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)
