ws-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike M. (JIRA)" <>
Subject [jira] [Commented] (WSS-652) MTOM Content-Id handling doesn't comply with RFC2392: .NET issues
Date Thu, 27 Jun 2019 11:23:00 GMT


Mike M. commented on WSS-652:

Thanks for the quick action, [~coheigea], and sorry for opening the ticket on the wrong project,
I wasn't sure whether it was just a WSS issue or a CXF-wide one.

I'll be back in office next week and will start work on validating this ASAP. Since I haven't
been able to reproduce the issue myself, testing your patch will involve a third party (.NET)
and might take a while. I'll get back here as soon as I have more information.

> MTOM Content-Id handling doesn't comply with RFC2392: .NET issues
> -----------------------------------------------------------------
>                 Key: WSS-652
>                 URL:
>             Project: WSS4J
>          Issue Type: Bug
>    Affects Versions: 2.2.3
>            Reporter: Mike M.
>            Assignee: Colm O hEigeartaigh
>            Priority: Blocker
>             Fix For: 2.3.0, 2.2.4
> 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:
> {code}
> Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
>         at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(
>         at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRef(
>         at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.decryptDataRefs(
>         at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(
>         at org.apache.wss4j.dom.processor.EncryptedKeyProcessor.handleToken(
>         at org.apache.wss4j.dom.engine.WSSecurityEngine.processSecurityHeader(
>         at
>         ... 54 common frames omitted
> Caused by: org.apache.wss4j.common.ext.WSSecurityException: Attachment not found
>         at org.apache.wss4j.dom.util.EncryptionUtils.decryptXopAttachment(
>         at org.apache.wss4j.dom.util.EncryptionUtils.decryptEncryptedData(
>         ... 60 common frames omitted
> {code}
> So at first, it looks like the incoming message has issues with Attachment IDs. Our actual
request looks like this (shortened for readability):
> {code}
> POST /myservice HTTP/1.1
> Host: localhost
> MIME-Version:1.0
> Content-Type:multipart/related; type="application/xop+xml";start="<>";boundary="uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1";start-info="text/xml"
> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
> Content-ID: <>
> Content-Transfer-Encoding: 8bit
> Content-Type: application/xop+xml;charset=utf-8;type="text/xml"
> <s:Envelope xmlns:s="">
> <s:Header>
> [...]
>    <Security>
>       [...]
>       <CipherData>
> 	     <CipherValue>
> 		    <xop:Include href="" xmlns:xop=""/>
>          </CipherValue>
> 	  </CipherData>
>       [...]
>    </Security>
> [...]
> </s:Header>
> <s:Body>
>    <EncryptedData>[...]</EncryptedData>
> </s:Body>
> </s:Envelope>
> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1
> Content-ID: <>
> Content-Transfer-Encoding: binary
> Content-Type: application/octet-stream
> [...binary data...]
> --uuid:fad7c6a9-85d1-498b-a456-748c87de4d7d+id=1--
> {code}
> 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
> As weird as this may seem, It's actually specified that way in those locations: 
> {quote}
> 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).
> {quote}
> {quote}
> 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
> {quote}
> So the value of {{<cop:Include>}}'s {{href}} attribute must always be URL-Encoded.
> As for the attachment part header, RFC2392 specifies the following:
> {quote}
>    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.
> {quote}
> 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 {{}},
it became apparent that when CXF generates those Attachement-IDs, it doesn't take the URL
Encoding into account either. It generated:
> {code}
> <xop:Include href="cid:http://75f2d83d-026b-44bf-8825-6bd2b693d60e"/>
> [...]
> Content-ID: <http://75f2d83d-026b-44bf-8825-6bd2b693d60e>
> {code}
> ... which violates the spec imho as {{<xop:Include>}}'s {{href}} contains non-URL-Encoded
> 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.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message