[
https://issues.apache.org/jira/browse/CXF-4099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated CXF-4099:
-----------------------------
Description:
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.
was:
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:
// 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.");
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.
> 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
