You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Colm O hEigeartaigh <co...@apache.org> on 2014/03/21 17:46:45 UTC
Signed/encrypted MTOM
Hi all,
CXF 3.0.0 will have the ability to sign and encrypt message attachments via
the SOAP with Attachments profile of WS-Security:
http://coheigea.blogspot.ie/2014/02/apache-wss4j-200-part-v.html
There have been a few inquiries about securing MTOM attachments and so I
thought I'd write up an email with what I intend to do, in case anyone has
any better ideas.
In CXF 2.6/2.7 MTOM Attachments are automatically inlined when using
WS-Security as there is no way to sign/encrypt attachments. Therefore the
whole point of using MTOM is lost.
There appears to be a near total lack of examples and documentation about
how MTOM and WS-Security should work together. However, it seems that it
should work by BASE-64 encoding the attachment + inlining it in the message
body temporarily, to calculate a Signature Digest. This BASE-64 encoding is
required on both the client + server side. This is obviously less efficient
that using the SOAP with Attachments approach which can just sign + encrypt
attachments "as is".
I propose the following for CXF 3.0.0:
a) Leave the current behaviour in place to inline attachments when using
MTOM. However, make this functionaltiy more sophisticated..e.g. no need to
do this when using the TransportBinding.
b) If you want to sign/encrypt MOTM attachments without inlining you can
simply configure the boolean switch on the WS-Security interceptors not to
inline + set the same "signature/encryptionParts" as for the SwA spec. This
will sign/encrypt the attachments, but e.g. only the xop:Include part will
be signed/encrypted in the SOAP Body.
If someone with expertise in using signed MTOM with Metro or WCF is will to
contribute a test-case then I can look into the interoperable inlining
approach for the next release.
Colm.
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Signed/encrypted MTOM
Posted by Daniel Kulp <dk...@apache.org>.
On Mar 24, 2014, at 6:26 AM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Hi Colm,
>
>
>> A test-case would be great. I don't feel it's realistic to support it in
>> CXF 3.0.0 though, we can always get it to work in CXF 3.0.1. For CXF 3.0.0
>> I will leave the current functionality in place, but make the inlining
>> behaviour more sophisticated (as I've described) for the TransportBinding.
>
> Do we have a target date for 3.0.0? That would be great to know, if so. :-)
Fairly soon. I was hoping in the next few weeks or so (early April timeframe), but we Talend folks keep getting pulled every which direction so getting the time to finish up the few outstanding issues is proving problematic. The good news is that it looks like the tests have become a lot more stable recently. That certainly helps my confidence level. Still have some outstanding functionality to deal with (some stuff in the JMS transport in particular, but a few other minor issues as well).
Dan
>
> - Dennis
>
>>
>> Colm.
>>
>>
>> On Sun, Mar 23, 2014 at 11:03 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>>
>>> Hi Colm,
>>>
>>> I think inlining is the way this needs to work, though I'd like to see
>>> some examples from other stacks (especially WCF) to be sure.
>>>
>>> But I'd think this would play well with the new streaming security code,
>>> at least for the signing case. When signing a message body with MTOM
>>> attachment you'd just need to use the inlining serializer to generate the
>>> byte stream, then when verifying the signature you'd do the same thing. Is
>>> that really much worse than handling SwA signed attachments?
>>>
>>> Encryption seems confusing to me, though. Do you have to encrypt the
>>> base64Binary data of the message? That's adding bloat that effects both
>>> message size and processing overhead, with double base64Binary encoding
>>> (both before and after encryption). Or does the <xop:Include> replace just
>>> the <xenc:CipherValue> part of the <xenc:EncryptedData> element, and the
>>> attachment is the actual encrypted data?
>>>
>>> One of my clients is working on providing a WCF test case for MTOM
>>> security, so hopefully we can see how that works.
>>>
>>> - Dennis
>>>
>>>
>>> On 03/24/2014 12:58 AM, Andrei Shakirin wrote:
>>>
>>>> Hi Colm,
>>>>
>>>> Sounds reasonable for me.
>>>> Only the concern is what we can do in case if
>>>> OnlySignEntireHeadersAndBody policy assertion is true and MTOM attachments
>>>> should be signed?
>>>> Accordingly spec only entire SOAP Body, a SOAP Header, and/or a direct
>>>> child of security header can be signed, nothing else.
>>>>
>>>> Does it make sense in this case to go way what you described: temporally
>>>> inline attachments to calculate digest value and send data as multipart
>>>> MTOM afterwards? In this case not only xop:Include part can be signed, but
>>>> whole message body including attachments as well. That can be useful for
>>>> same use cases where ensuring consistency between message body and
>>>> attachments is important.
>>>>
>>>> Regards,
>>>> Andrei.
>>>>
>>>> -----Original Message-----
>>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>>> Sent: Freitag, 21. März 2014 17:47
>>>>> To: users@cxf.apache.org
>>>>> Subject: Signed/encrypted MTOM
>>>>>
>>>>> Hi all,
>>>>>
>>>>> CXF 3.0.0 will have the ability to sign and encrypt message attachments
>>>>> via the
>>>>> SOAP with Attachments profile of WS-Security:
>>>>>
>>>>> http://coheigea.blogspot.ie/2014/02/apache-wss4j-200-part-v.html
>>>>>
>>>>> There have been a few inquiries about securing MTOM attachments and so I
>>>>> thought I'd write up an email with what I intend to do, in case anyone
>>>>> has any
>>>>> better ideas.
>>>>>
>>>>> In CXF 2.6/2.7 MTOM Attachments are automatically inlined when using WS-
>>>>> Security as there is no way to sign/encrypt attachments. Therefore the
>>>>> whole
>>>>> point of using MTOM is lost.
>>>>>
>>>>> There appears to be a near total lack of examples and documentation about
>>>>> how MTOM and WS-Security should work together. However, it seems that it
>>>>> should work by BASE-64 encoding the attachment + inlining it in the
>>>>> message
>>>>> body temporarily, to calculate a Signature Digest. This BASE-64 encoding
>>>>> is
>>>>> required on both the client + server side. This is obviously less
>>>>> efficient that
>>>>> using the SOAP with Attachments approach which can just sign + encrypt
>>>>> attachments "as is".
>>>>>
>>>>> I propose the following for CXF 3.0.0:
>>>>>
>>>>> a) Leave the current behaviour in place to inline attachments when using
>>>>> MTOM. However, make this functionaltiy more sophisticated..e.g. no need
>>>>> to
>>>>> do this when using the TransportBinding.
>>>>>
>>>>> b) If you want to sign/encrypt MOTM attachments without inlining you can
>>>>> simply configure the boolean switch on the WS-Security interceptors not
>>>>> to
>>>>> inline + set the same "signature/encryptionParts" as for the SwA spec.
>>>>> This will
>>>>> sign/encrypt the attachments, but e.g. only the xop:Include part will be
>>>>> signed/encrypted in the SOAP Body.
>>>>>
>>>>> If someone with expertise in using signed MTOM with Metro or WCF is will
>>>>> to
>>>>> contribute a test-case then I can look into the interoperable inlining
>>>>> approach
>>>>> for the next release.
>>>>>
>>>>> Colm.
>>>>>
>>>>>
>>>>> --
>>>>> Colm O hEigeartaigh
>>>>>
>>>>> Talend Community Coder
>>>>> http://coders.talend.com
>>>>>
>>
>
--
Daniel Kulp
dkulp@apache.org - http://dankulp.com/blog
Talend Community Coder - http://coders.talend.com
Re: Signed/encrypted MTOM
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Colm,
On 03/24/2014 11:10 PM, Colm O hEigeartaigh wrote:
>> Is that really much worse than handling SwA signed attachments?
> My understanding is that a BASE-64 encoding/decoding step is required for
> the inlining case, which is not required for SwA.
Yes, I believe that's correct from what we know. But streaming
conversion of binary bytes to base64Binary is pretty easy.
> A test-case would be great. I don't feel it's realistic to support it in
> CXF 3.0.0 though, we can always get it to work in CXF 3.0.1. For CXF 3.0.0
> I will leave the current functionality in place, but make the inlining
> behaviour more sophisticated (as I've described) for the TransportBinding.
Do we have a target date for 3.0.0? That would be great to know, if so. :-)
- Dennis
>
> Colm.
>
>
> On Sun, Mar 23, 2014 at 11:03 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
>
>> Hi Colm,
>>
>> I think inlining is the way this needs to work, though I'd like to see
>> some examples from other stacks (especially WCF) to be sure.
>>
>> But I'd think this would play well with the new streaming security code,
>> at least for the signing case. When signing a message body with MTOM
>> attachment you'd just need to use the inlining serializer to generate the
>> byte stream, then when verifying the signature you'd do the same thing. Is
>> that really much worse than handling SwA signed attachments?
>>
>> Encryption seems confusing to me, though. Do you have to encrypt the
>> base64Binary data of the message? That's adding bloat that effects both
>> message size and processing overhead, with double base64Binary encoding
>> (both before and after encryption). Or does the <xop:Include> replace just
>> the <xenc:CipherValue> part of the <xenc:EncryptedData> element, and the
>> attachment is the actual encrypted data?
>>
>> One of my clients is working on providing a WCF test case for MTOM
>> security, so hopefully we can see how that works.
>>
>> - Dennis
>>
>>
>> On 03/24/2014 12:58 AM, Andrei Shakirin wrote:
>>
>>> Hi Colm,
>>>
>>> Sounds reasonable for me.
>>> Only the concern is what we can do in case if
>>> OnlySignEntireHeadersAndBody policy assertion is true and MTOM attachments
>>> should be signed?
>>> Accordingly spec only entire SOAP Body, a SOAP Header, and/or a direct
>>> child of security header can be signed, nothing else.
>>>
>>> Does it make sense in this case to go way what you described: temporally
>>> inline attachments to calculate digest value and send data as multipart
>>> MTOM afterwards? In this case not only xop:Include part can be signed, but
>>> whole message body including attachments as well. That can be useful for
>>> same use cases where ensuring consistency between message body and
>>> attachments is important.
>>>
>>> Regards,
>>> Andrei.
>>>
>>> -----Original Message-----
>>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>>> Sent: Freitag, 21. März 2014 17:47
>>>> To: users@cxf.apache.org
>>>> Subject: Signed/encrypted MTOM
>>>>
>>>> Hi all,
>>>>
>>>> CXF 3.0.0 will have the ability to sign and encrypt message attachments
>>>> via the
>>>> SOAP with Attachments profile of WS-Security:
>>>>
>>>> http://coheigea.blogspot.ie/2014/02/apache-wss4j-200-part-v.html
>>>>
>>>> There have been a few inquiries about securing MTOM attachments and so I
>>>> thought I'd write up an email with what I intend to do, in case anyone
>>>> has any
>>>> better ideas.
>>>>
>>>> In CXF 2.6/2.7 MTOM Attachments are automatically inlined when using WS-
>>>> Security as there is no way to sign/encrypt attachments. Therefore the
>>>> whole
>>>> point of using MTOM is lost.
>>>>
>>>> There appears to be a near total lack of examples and documentation about
>>>> how MTOM and WS-Security should work together. However, it seems that it
>>>> should work by BASE-64 encoding the attachment + inlining it in the
>>>> message
>>>> body temporarily, to calculate a Signature Digest. This BASE-64 encoding
>>>> is
>>>> required on both the client + server side. This is obviously less
>>>> efficient that
>>>> using the SOAP with Attachments approach which can just sign + encrypt
>>>> attachments "as is".
>>>>
>>>> I propose the following for CXF 3.0.0:
>>>>
>>>> a) Leave the current behaviour in place to inline attachments when using
>>>> MTOM. However, make this functionaltiy more sophisticated..e.g. no need
>>>> to
>>>> do this when using the TransportBinding.
>>>>
>>>> b) If you want to sign/encrypt MOTM attachments without inlining you can
>>>> simply configure the boolean switch on the WS-Security interceptors not
>>>> to
>>>> inline + set the same "signature/encryptionParts" as for the SwA spec.
>>>> This will
>>>> sign/encrypt the attachments, but e.g. only the xop:Include part will be
>>>> signed/encrypted in the SOAP Body.
>>>>
>>>> If someone with expertise in using signed MTOM with Metro or WCF is will
>>>> to
>>>> contribute a test-case then I can look into the interoperable inlining
>>>> approach
>>>> for the next release.
>>>>
>>>> Colm.
>>>>
>>>>
>>>> --
>>>> Colm O hEigeartaigh
>>>>
>>>> Talend Community Coder
>>>> http://coders.talend.com
>>>>
>
Re: Signed/encrypted MTOM
Posted by Colm O hEigeartaigh <co...@apache.org>.
Hi Dennis,
> Is that really much worse than handling SwA signed attachments?
My understanding is that a BASE-64 encoding/decoding step is required for
the inlining case, which is not required for SwA.
> Encryption seems confusing to me, though. Do you have to encrypt the
base64Binary data of the message? That's adding bloat
> that effects both message size and processing overhead, with double
base64Binary encoding (both before and after encryption).
> Or does the <xop:Include> replace just the <xenc:CipherValue> part of the
<xenc:EncryptedData> element, and the attachment
> is the actual encrypted data?
Good question :-) I suspect using the SwA approach is better for encryption.
> One of my clients is working on providing a WCF test case for MTOM
security, so hopefully we can see how that works.
A test-case would be great. I don't feel it's realistic to support it in
CXF 3.0.0 though, we can always get it to work in CXF 3.0.1. For CXF 3.0.0
I will leave the current functionality in place, but make the inlining
behaviour more sophisticated (as I've described) for the TransportBinding.
Colm.
On Sun, Mar 23, 2014 at 11:03 PM, Dennis Sosnoski <dm...@sosnoski.com> wrote:
> Hi Colm,
>
> I think inlining is the way this needs to work, though I'd like to see
> some examples from other stacks (especially WCF) to be sure.
>
> But I'd think this would play well with the new streaming security code,
> at least for the signing case. When signing a message body with MTOM
> attachment you'd just need to use the inlining serializer to generate the
> byte stream, then when verifying the signature you'd do the same thing. Is
> that really much worse than handling SwA signed attachments?
>
> Encryption seems confusing to me, though. Do you have to encrypt the
> base64Binary data of the message? That's adding bloat that effects both
> message size and processing overhead, with double base64Binary encoding
> (both before and after encryption). Or does the <xop:Include> replace just
> the <xenc:CipherValue> part of the <xenc:EncryptedData> element, and the
> attachment is the actual encrypted data?
>
> One of my clients is working on providing a WCF test case for MTOM
> security, so hopefully we can see how that works.
>
> - Dennis
>
>
> On 03/24/2014 12:58 AM, Andrei Shakirin wrote:
>
>> Hi Colm,
>>
>> Sounds reasonable for me.
>> Only the concern is what we can do in case if
>> OnlySignEntireHeadersAndBody policy assertion is true and MTOM attachments
>> should be signed?
>> Accordingly spec only entire SOAP Body, a SOAP Header, and/or a direct
>> child of security header can be signed, nothing else.
>>
>> Does it make sense in this case to go way what you described: temporally
>> inline attachments to calculate digest value and send data as multipart
>> MTOM afterwards? In this case not only xop:Include part can be signed, but
>> whole message body including attachments as well. That can be useful for
>> same use cases where ensuring consistency between message body and
>> attachments is important.
>>
>> Regards,
>> Andrei.
>>
>> -----Original Message-----
>>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>>> Sent: Freitag, 21. März 2014 17:47
>>> To: users@cxf.apache.org
>>> Subject: Signed/encrypted MTOM
>>>
>>> Hi all,
>>>
>>> CXF 3.0.0 will have the ability to sign and encrypt message attachments
>>> via the
>>> SOAP with Attachments profile of WS-Security:
>>>
>>> http://coheigea.blogspot.ie/2014/02/apache-wss4j-200-part-v.html
>>>
>>> There have been a few inquiries about securing MTOM attachments and so I
>>> thought I'd write up an email with what I intend to do, in case anyone
>>> has any
>>> better ideas.
>>>
>>> In CXF 2.6/2.7 MTOM Attachments are automatically inlined when using WS-
>>> Security as there is no way to sign/encrypt attachments. Therefore the
>>> whole
>>> point of using MTOM is lost.
>>>
>>> There appears to be a near total lack of examples and documentation about
>>> how MTOM and WS-Security should work together. However, it seems that it
>>> should work by BASE-64 encoding the attachment + inlining it in the
>>> message
>>> body temporarily, to calculate a Signature Digest. This BASE-64 encoding
>>> is
>>> required on both the client + server side. This is obviously less
>>> efficient that
>>> using the SOAP with Attachments approach which can just sign + encrypt
>>> attachments "as is".
>>>
>>> I propose the following for CXF 3.0.0:
>>>
>>> a) Leave the current behaviour in place to inline attachments when using
>>> MTOM. However, make this functionaltiy more sophisticated..e.g. no need
>>> to
>>> do this when using the TransportBinding.
>>>
>>> b) If you want to sign/encrypt MOTM attachments without inlining you can
>>> simply configure the boolean switch on the WS-Security interceptors not
>>> to
>>> inline + set the same "signature/encryptionParts" as for the SwA spec.
>>> This will
>>> sign/encrypt the attachments, but e.g. only the xop:Include part will be
>>> signed/encrypted in the SOAP Body.
>>>
>>> If someone with expertise in using signed MTOM with Metro or WCF is will
>>> to
>>> contribute a test-case then I can look into the interoperable inlining
>>> approach
>>> for the next release.
>>>
>>> Colm.
>>>
>>>
>>> --
>>> Colm O hEigeartaigh
>>>
>>> Talend Community Coder
>>> http://coders.talend.com
>>>
>>
>
--
Colm O hEigeartaigh
Talend Community Coder
http://coders.talend.com
Re: Signed/encrypted MTOM
Posted by Dennis Sosnoski <dm...@sosnoski.com>.
Hi Colm,
I think inlining is the way this needs to work, though I'd like to see
some examples from other stacks (especially WCF) to be sure.
But I'd think this would play well with the new streaming security code,
at least for the signing case. When signing a message body with MTOM
attachment you'd just need to use the inlining serializer to generate
the byte stream, then when verifying the signature you'd do the same
thing. Is that really much worse than handling SwA signed attachments?
Encryption seems confusing to me, though. Do you have to encrypt the
base64Binary data of the message? That's adding bloat that effects both
message size and processing overhead, with double base64Binary encoding
(both before and after encryption). Or does the <xop:Include> replace
just the <xenc:CipherValue> part of the <xenc:EncryptedData> element,
and the attachment is the actual encrypted data?
One of my clients is working on providing a WCF test case for MTOM
security, so hopefully we can see how that works.
- Dennis
On 03/24/2014 12:58 AM, Andrei Shakirin wrote:
> Hi Colm,
>
> Sounds reasonable for me.
> Only the concern is what we can do in case if OnlySignEntireHeadersAndBody policy assertion is true and MTOM attachments should be signed?
> Accordingly spec only entire SOAP Body, a SOAP Header, and/or a direct child of security header can be signed, nothing else.
>
> Does it make sense in this case to go way what you described: temporally inline attachments to calculate digest value and send data as multipart MTOM afterwards? In this case not only xop:Include part can be signed, but whole message body including attachments as well. That can be useful for same use cases where ensuring consistency between message body and attachments is important.
>
> Regards,
> Andrei.
>
>> -----Original Message-----
>> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
>> Sent: Freitag, 21. März 2014 17:47
>> To: users@cxf.apache.org
>> Subject: Signed/encrypted MTOM
>>
>> Hi all,
>>
>> CXF 3.0.0 will have the ability to sign and encrypt message attachments via the
>> SOAP with Attachments profile of WS-Security:
>>
>> http://coheigea.blogspot.ie/2014/02/apache-wss4j-200-part-v.html
>>
>> There have been a few inquiries about securing MTOM attachments and so I
>> thought I'd write up an email with what I intend to do, in case anyone has any
>> better ideas.
>>
>> In CXF 2.6/2.7 MTOM Attachments are automatically inlined when using WS-
>> Security as there is no way to sign/encrypt attachments. Therefore the whole
>> point of using MTOM is lost.
>>
>> There appears to be a near total lack of examples and documentation about
>> how MTOM and WS-Security should work together. However, it seems that it
>> should work by BASE-64 encoding the attachment + inlining it in the message
>> body temporarily, to calculate a Signature Digest. This BASE-64 encoding is
>> required on both the client + server side. This is obviously less efficient that
>> using the SOAP with Attachments approach which can just sign + encrypt
>> attachments "as is".
>>
>> I propose the following for CXF 3.0.0:
>>
>> a) Leave the current behaviour in place to inline attachments when using
>> MTOM. However, make this functionaltiy more sophisticated..e.g. no need to
>> do this when using the TransportBinding.
>>
>> b) If you want to sign/encrypt MOTM attachments without inlining you can
>> simply configure the boolean switch on the WS-Security interceptors not to
>> inline + set the same "signature/encryptionParts" as for the SwA spec. This will
>> sign/encrypt the attachments, but e.g. only the xop:Include part will be
>> signed/encrypted in the SOAP Body.
>>
>> If someone with expertise in using signed MTOM with Metro or WCF is will to
>> contribute a test-case then I can look into the interoperable inlining approach
>> for the next release.
>>
>> Colm.
>>
>>
>> --
>> Colm O hEigeartaigh
>>
>> Talend Community Coder
>> http://coders.talend.com
RE: Signed/encrypted MTOM
Posted by Andrei Shakirin <as...@talend.com>.
Hi Colm,
Sounds reasonable for me.
Only the concern is what we can do in case if OnlySignEntireHeadersAndBody policy assertion is true and MTOM attachments should be signed?
Accordingly spec only entire SOAP Body, a SOAP Header, and/or a direct child of security header can be signed, nothing else.
Does it make sense in this case to go way what you described: temporally inline attachments to calculate digest value and send data as multipart MTOM afterwards? In this case not only xop:Include part can be signed, but whole message body including attachments as well. That can be useful for same use cases where ensuring consistency between message body and attachments is important.
Regards,
Andrei.
> -----Original Message-----
> From: Colm O hEigeartaigh [mailto:coheigea@apache.org]
> Sent: Freitag, 21. März 2014 17:47
> To: users@cxf.apache.org
> Subject: Signed/encrypted MTOM
>
> Hi all,
>
> CXF 3.0.0 will have the ability to sign and encrypt message attachments via the
> SOAP with Attachments profile of WS-Security:
>
> http://coheigea.blogspot.ie/2014/02/apache-wss4j-200-part-v.html
>
> There have been a few inquiries about securing MTOM attachments and so I
> thought I'd write up an email with what I intend to do, in case anyone has any
> better ideas.
>
> In CXF 2.6/2.7 MTOM Attachments are automatically inlined when using WS-
> Security as there is no way to sign/encrypt attachments. Therefore the whole
> point of using MTOM is lost.
>
> There appears to be a near total lack of examples and documentation about
> how MTOM and WS-Security should work together. However, it seems that it
> should work by BASE-64 encoding the attachment + inlining it in the message
> body temporarily, to calculate a Signature Digest. This BASE-64 encoding is
> required on both the client + server side. This is obviously less efficient that
> using the SOAP with Attachments approach which can just sign + encrypt
> attachments "as is".
>
> I propose the following for CXF 3.0.0:
>
> a) Leave the current behaviour in place to inline attachments when using
> MTOM. However, make this functionaltiy more sophisticated..e.g. no need to
> do this when using the TransportBinding.
>
> b) If you want to sign/encrypt MOTM attachments without inlining you can
> simply configure the boolean switch on the WS-Security interceptors not to
> inline + set the same "signature/encryptionParts" as for the SwA spec. This will
> sign/encrypt the attachments, but e.g. only the xop:Include part will be
> signed/encrypted in the SOAP Body.
>
> If someone with expertise in using signed MTOM with Metro or WCF is will to
> contribute a test-case then I can look into the interoperable inlining approach
> for the next release.
>
> Colm.
>
>
> --
> Colm O hEigeartaigh
>
> Talend Community Coder
> http://coders.talend.com