[
https://issues.apache.org/jira/browse/CXF-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Colm O hEigeartaigh updated CXF-4099:
-------------------------------------
Fix Version/s: 2.6
2.5.3
2.4.7
> SignedParts, EncryptedParts policy assertions are silently ignored on the
> client side if specified alone
> --------------------------------------------------------------------------------------------------------
>
> Key: CXF-4099
> URL: https://issues.apache.org/jira/browse/CXF-4099
> Project: CXF
> Issue Type: Bug
> Components: WS-* Components
> Reporter: Andrei Shakirin
> Assignee: Colm O hEigeartaigh
> Fix For: 2.4.7, 2.5.3, 2.6
>
> Attachments: cxf-rt-ws-security.patch
>
>
> Hi,
> Actually if client defines policy containing only SignedParts, EncryptedParts
> assertions without binding (Assymetric, Symmetric or Transport) CXF does
> nothing and send unsigned/unencrypted message. Exception is thrown only on
> service side (Assertion is not satisfied). I find it a little bit dangerous,
> because client can assume that message is encrypted. IMHO exception should be
> thrown already on client side.
> Fix proposals:
> A) PolicyVerificationOutInterceptor
> As I can see PolicyVerificationOutInterceptor doesn't throw exception in case
> if policy assertions are not satisfied.
> That means for outgoing messages (client request and server response) policy
> assertions can be not fulfilled and message will be sent anyway.
> Code is below:
> {code:java}
> // CXF-1849 Log a message at FINE level if policy verification fails
> // on the outbound-server side of a response
> try {
> aim.checkEffectivePolicy(policy.getPolicy());
> } catch (PolicyException e) {
> LOG.fine("An exception was thrown when verifying that the
> effective policy for "
> + "this request was satisfied. However, this exception
> will not result in "
> + "a fault. The exception raised is: "
> + e.toString());
> return;
> }
> LOG.fine("Verified policies for outbound message.");
> {code}
> For incoming messages unsatisfied assertion is interpreted as real problem
> and causes fault.
> I am not sure about the reason of such different verification.
> There are some cases where it can be critical even for outgoing message:
> encryption, compression.
> B) If alternative A is not possible for some reasons, I would propose to
> implement additional interceptor, register it in
> WSSecurityPolicyInterceptorProvider and check specially for critcal security
> assertion satisfaction there. Interceptor should be called after
> PolicyBasedWSS4J* interceptors.
> I am going to provide a patch either for A or B.
> Regards,
> Andrei.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
