Hi Colm,

One more question in context of the second problem:
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.

Do you know what is the reason of such different verification?
There are some cases where it can be critical even for outgoing message: 
encryption, compression.

Regards,
Andrei.

-----Original Message-----
From: Andrei Shakirin [mailto:[email protected]] 
Sent: 09 February 2012 10:00
To: [email protected]; [email protected]
Subject: RE: Signature and encryption in security policy

Hi Colm,

>> 2)      Actually if client defines policy containing only SignedParts, 
>> EncryptedParts assertions 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.

>Could you raise a JIRA for this?

Sure, I also will try to provide a patch :)

Regards,
Andrei.

-----Original Message-----
From: Colm O hEigeartaigh [mailto:[email protected]] 
Sent: 08 February 2012 17:03
To: [email protected]
Subject: Re: Signature and encryption in security policy

Hi Andrei,

Yes, we only support Signed/Encrypted Parts with a security binding.

> 1)      Basically I can see some use cases where signing/encryption can be 
> done without authentication, for example encryption request only. In this 
> case client just get public key of service and encrypt request message. 
> Actually, client haven't authenticate itself for this scenario. Are there 
> special reasons always to bind SignedParts, EncryptedParts with 
> AssymetricBinding, SymmetricBinding or TransportBinding?

Specifying a binding does not imply authentication. So for example, if you just 
want to encrypt the message, you just specify an EncryptedParts policy with the 
relevant binding, and it should work fine. One caveat to this is if a Timestamp 
is included, then it is signed as per the spec. In addition, using a binding 
gives guarantees on key-sizes, algorithms etc. via an AlgorithmSuite policy. In 
short, I don't really see a use-case for allowing the user to specify an 
EncryptedParts without a binding.

> 2)      Actually if client defines policy containing only SignedParts, 
> EncryptedParts assertions 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.

Could you raise a JIRA for this?

Colm.

On Wed, Feb 8, 2012 at 3:42 PM, Andrei Shakirin <[email protected]> wrote:
> Hi,
>
> Would like to discuss two topics regarding WS-Policy security implementation.
>
> Signature and encryption of request are controlled by SignedParts, 
> EncryptedParts policy assertions.
> But, as far as I can see, these assertions can be active only together with 
> AssymetricBinding, SymmetricBinding or TransportBinding assertions.
> Asymmetric/Symmetric BindingHandler get signing/encryption element lists from 
> AbstractBindingHandler and call appropriate WSS4J function to sign or encrypt 
> message parts.
> Asymmetric/Symmetric BindingHandler is called from 
> PolicyBasedWSS4JOutInterceptorInternal interceptor associated with 
> AssymetricBinding, SymmetricBinding or TransportBinding assertions.
> That means, if client has a policy ONLY with SignedParts, EncryptedParts 
> assertions, WITHOUT AssymetricBinding, SymmetricBinding or TransportBinding 
> it does nothing with message.
>
> Two questions:
>
> 1)      Basically I can see some use cases where signing/encryption can be 
> done without authentication, for example encryption request only. In this 
> case client just get public key of service and encrypt request message. 
> Actually, client haven't authenticate itself for this scenario. Are there 
> special reasons always to bind SignedParts, EncryptedParts with 
> AssymetricBinding, SymmetricBinding or TransportBinding?
>
> 2)      Actually if client defines policy containing only SignedParts, 
> EncryptedParts assertions 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.
>
> Regards,
> Andrei.
>



--
Colm O hEigeartaigh

Talend Community Coder
http://coders.talend.com

Reply via email to