You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Andrei Shakirin <as...@talend.com> on 2012/02/08 16:42:02 UTC
Signature and encryption in security policy
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.
RE: Signature and encryption in security policy
Posted by Andrei Shakirin <as...@talend.com>.
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:ashakirin@talend.com]
Sent: 09 February 2012 10:00
To: users@cxf.apache.org; coheigea@apache.org
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:coheigea@apache.org]
Sent: 08 February 2012 17:03
To: users@cxf.apache.org
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 <as...@talend.com> 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
RE: Signature and encryption in security policy
Posted by Andrei Shakirin <as...@talend.com>.
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:coheigea@apache.org]
Sent: 08 February 2012 17:03
To: users@cxf.apache.org
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 <as...@talend.com> 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
Re: Signature and encryption in security policy
Posted by Colm O hEigeartaigh <co...@apache.org>.
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 <as...@talend.com> 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