Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Thu, 16 Feb 2012 18:54:59 +0000 (UTC)
From: "Colm O hEigeartaigh (Resolved) (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <694417032.47229.1329418499621.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <795341083.24381.1328886064592.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (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:all-tabpanel ]

Colm O hEigeartaigh resolved CXF-4099.
--------------------------------------

    Resolution: Fixed
    
> 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