Blocker Description
We found an issue when a CXF server is being called from a .NET client with WebService Security and MTOM in place. The relevant part of the stack trace looks like this:
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:215)
at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRef(EncryptedKeyProcessor.java:602)
at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRefs(EncryptedKeyProcessor.java:533)
at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:232)
at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(EncryptedKeyProcessor.java:90)
at org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(WSSecurityEngine.java:340)
at org.apache.cxf.ws.security.wss4j.WSS4JInInterceptor.handleMessageInternal(WSS4JInInterceptor.java:320)
... 54 common frames omitted
Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
at org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(EncryptionUtils.java:376)
at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(EncryptionUtils.java:207)
... 60 common frames omitted
So at first, it looks like the incoming message has issues with Attachment IDs. Our actual request looks like this (shortened for readability):
POST /myservice HTTP/1.1 Host: localhost MIME-Version:1.0 Content-Type:multipart/related; type="application/xop+xml";start="<http://tempuri.org/0>";boundary="uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1";start-info="text/xml" --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1 Content-ID: <http://tempuri.org/0> Content-Transfer-Encoding: 8bit Content-Type: application/xop+xml;charset=utf-8;type="text/xml" <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/"> <s:Header> [...] <Security> [...] <CipherData> <CipherValue> <xop:Include href="cid:http%3A%2F%2Ftempuri.org%2F1%2F636966400494014846" xmlns:xop="http://www.w3.org/2004/08/xop/include"/> </CipherValue> </CipherData> [...] </Security> [...] </s:Header> <s:Body> <EncryptedData>[...]</EncryptedData> </s:Body> </s:Envelope> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1 Content-ID: <http://tempuri.org/1/636966400494014846> Content-Transfer-Encoding: binary Content-Type: application/octet-stream [...binary data...] --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1--
Now, if you compare <xop:Include>'s href value with the Content-ID in the attachment part header, you'll see that it is the same value, just URL-Encoded in the former.
As weird as this may seem, It's actually specified that way in those locations:
https://www.w3.org/TR/xop10/#xop_href
The href attribute information item has:
A [normalized value] which is a representation of a URI referencing the part of the package containing the data logically included by the [owner element] (i.e., the xop:Include element information item). The [normalized value] MUST be a valid URI per the cid: URI scheme (see [RFC 2392]). In addition, the [normalized value] MUST be a valid lexical form of the XML Schema xs:anyURI datatype (see [XML Schema Part 2: Datatypes Second Edition]3.2.17 anyURI).
https://tools.ietf.org/html/rfc2392
2. The MID and CID URL Schemes
The URLs take the form
content-id = url-addr-spec
message-id = url-addr-spec
url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec
cid-url = "cid" ":" content-id
So the value of <cop:Include>'s href attribute must always be URL-Encoded.
As for the attachment part header, RFC2392 specifies the following:
A "cid" URL is converted to the corresponding Content-ID message
header [MIME] by removing the "cid:" prefix, converting the % encoded
character to their equivalent US-ASCII characters, and enclosing the
remaining parts with an angle bracket pair, "<" and ">".Reversing the process and converting URL special characters to their
% encodings produces the original cid.
It looks to us as if CXF didn't take that URL-Encoding from the Specifications into account when looking up MIME Attachments.
When I tried to reproduce the issue by forcing some special characters (in the form of a prepended "http://") into the generated Attachement-ID in org.apache.xml.security.stax.impl.util.IDGenerator, it became apparent that when CXF generates those Attachement-IDs, it doesn't take the URL Encoding into account either. It generated:
<xop:Include href="cid:http://75f2d83d-026b-44bf-8825-6bd2b693d60e"/> [...] Content-ID: <http://75f2d83d-026b-44bf-8825-6bd2b693d60e>
... which violates the spec imho as <xop:Include>'s href contains non-URL-Encoded characters.
That last bit (CXF generating messages) wouldn't be too much of an issue to me personally, but CXF failing with what appears to be Spec-Compliant messages must be considered a bug imho.
To reiterate: this issue prevents CXF from being compatible with the .NET SOAP / WebService Security stack and is a blocker for us.