Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Tue, 14 Feb 2012 14:00:59 +0000 (UTC)
From: "Andrei Shakirin (Issue Comment Edited) (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1867983823.36403.1329228059843.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <795341083.24381.1328886064592.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (CXF-4099) SignedParts,
 EncryptedParts policy assertions are silently ignored on the client side if
 specified alone
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CXF-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13207650#comment-13207650 ] 

Andrei Shakirin edited comment on CXF-4099 at 2/14/12 2:00 PM:
---------------------------------------------------------------

Hi Dan and Colm,

OK, now I see the issue with PolicyVerificationOutInterceptor: 
- from one side it should be called late, because it is possible that some interceptors are invoked on SEND or POST_STREAM phases and they satisfy corresponded policy assertions
- from other side as far as it is called after MessageSenderInterceptor, Conduit already opens the connection and sets OutputStream into message. It is also possible that message is already partly sent until PolicyVerificationOutInterceptor is called.

Unfortunatelly it is not directly possible to fix it in PolicyBasedWSS4JOutInterceptor, because this interceptor is associated with binding assertions (TRANSPORT_BINDING, ASSYMETRIC_BINDING, SYMMETRIC_BINDING). If binding is not specified at all, interceptor will not be activated. I will try to provide patch for alternative 2.

Other question: does it make sense to throw exception in PolicyBasedWSS4JOutInterceptor anyway, if assertion is not satisfied? In some cases message is still not sent, if it is partly send - ok, better later as never :)
My concern that it is possible to have other, non-security assertions that also can be critical for client, for example custom compression. If assertion for some reasons is not satisfied on the client side, why not throw the exception instead send huge uncompressed message? Verify every individual assertion can be quite complicated.

Regards,
Andrei.
                
      was (Author: ashakirin):
    Hi Dan and Colm,

OK, now I see the issue with PolicyVerificationOutInterceptor: 
- from one side it should be called late, because it is possible that some interceptors are invoked on SEND or POST_STREAM phases and they satisfy corresponded policy assertions
- from other side as far as it is called after MessageSenderInterceptor, Conduit already opens the connection and sets OutputStream into message. It is also possible that message is already partly sent until PolicyVerificationOutInterceptor is called.
I will follow your suggestion and fix it into PolicyBasedWSS4JOutInterceptor.

But does it make sense to throw exception in PolicyBasedWSS4JOutInterceptor anyway, if assertion is not satisfied? In some cases message is still not sent, if it is partly send - ok, better later as never :)
My concern that it is possible to have other, non-security assertions that also can be critical for client, for example custom compression. If assertion for some reasons is not satisfied on the client side, why not throw the exception instead send huge uncompressed message? Verify every individual assertion can be quite complicated.

Regards,
Andrei.
                  
> 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
>
> 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